My understanding of the problems (templates, plugins, ....) is that we
won't be able to find a perfect general solution, since every single
webapp use its own templates, its own plugins, ...
My suggestion is that we could define some 'profiles' of webapp, and
that every webapp would inherit from those profiles.
e.g, we could say that a webapp that uses a SGDB has to provide :
db_create
db_delete
db_save
db_restore
db_upgrade
and that *every* single webapp should provide :
cfg_new (to create an instance)
cfg_delete (to delete one)
cfg_is_multiple (does the app support multiple instances
in its actual form)
...
and so on.
and packaging a webapp would be to instanciate thoses APIs and let a
webapp-config tool use all those functions and deal with it alone.
Maybe some pple here know drupal internals, it's how they have thought
their module system, and it is really really nice and easy to use. One
only has to tell what he needs/provide, and then to implement the
related functions.
In fact, listing the problems is nice, and important. though, I think
that listing all the properties, all the task we want a package to be
able to have/manage is important too. In fact I believe both are really
related.
For some problems, there would be quite very common solutions, and code
sharing will be optimal. for others, we won't have generic solution,
but the generic API will tell to the user what we actually support.
e.g., if the tpl_ functions are not implemented, user will *know* we
don't support any kind of templating on that package. if those are, he
will know (because those feature will be documented) where he may but
his templates, plugins and so on. maybe some apps won't permit to have
the plain /usr/share/$webapp/plugin + /usr/local/..../plugin dir, and
we should then maybe provide some CLI tools that would install such
plugins using the same mechanism as before (using some plug_install
plug_remove and alike functions)
So now that we already have a quite long list of common problems (that
will grow, but we can deal with it incrementaly) maybe we should list
all the features we (may) want, and then decide if we only list those
in a policy, and let the maintainers deal with this list, or if we
provide some fancy tool like I suggest (or any other solution we can
imagine)
--
·O· Pierre Habouzit
··O
OOO http://www.madism.org
Attachment:
pgpmHeVfKdg07.pgp
Description: PGP signature