Hi,
Following Berin's habits of publishing seeds for public brainstorming, I'd like
to hear your feelings about the need for component packaging in C2.
A look at the evolution of the stock sitemap.xmap reveals a growing number of
components. This is natural, and is a Good Thing(tm). C2 users are adapting
C2 to a growing number of demands, and this is one of the paths to do it.
It is just expectable that, as the user base grows, and C2 API stabilizes, more
and more C2 components see the daylight.
I see one problem, though. Currently, all components become part of Cocoon's codebase.
This somewhat increases C2 complexity for developers, but unquestionably raises
management problems.
When it comes to componentized development, I like to think of a CPAN like scenario.
Among perl's many virtues and defects, one undisputed excellent feature is the
component repository. If an architecure has the ability to be extended through
components, I think it should aim to have its own CPAN: distributed development and
testing of components, with easy deployment mechanisms and a central component
registry.
If C2 ever reached the number of components perl has today, the number of commiters
would be astonishing, and codebase management (permissions, QA, etc) would be a
nightmare. Clearly, if the objective is to have a large number of components,
components should be easily detachable from core cocoon.
What would a component packaging system require? I guess an existing packaging format
may be reusable for these needs. A component-contained configuration might be needed.
Here I don't have a formed opinion, other than thinking component declaration shouldn't
be in the sitemap. Please kick in and write back.
--
Sergio Carvalho
---------------
[EMAIL PROTECTED]
If at first you don't succeed, skydiving is not for you
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
