Leo Simons wrote:
Ulrich Mayring wrote:If it's possible I'm all for it. So far Cocoon is a major customer, maybe there are some others, I don't know. But once you have a number of major customers like Cocoon my guess is you won't be able to make all of them happy with a �ber-container. But, as I said, I'd love to be proven wrong :)
Probably. But the idea is to do a proper extraction of that container framework and do as much work as possible within the avalon scope. Peeps are talking of building "profiles" on top of such a framework to handle more specific needs, with easy tweaking of those profiles for your application-specific needs. SoC, really.
So, to me the interesting question is: what do we give up if we give up on a block-concept and instead rely only on a component concept?are you referring to cocoon or in general? In general application decomposition, we often find logical partitions of the application into components, and then logical partition of those components into subcomponents, up to a level where a subsubsubcomponent becomes to small as to warrant the component management overhead.
I was talking about application development in general.
arbitrary partitioning is an application-neutral concern. I'm guessing a cocoon block model would be application-specific, with a large part addressable by application-neutral stuff. We need to figure out how avalon can provide the application-neutral stuff, and also make it easy for cocoon to put the application-specific stuff on top of that.What do you mean by arbitrary partitioning? There already is arbitrary partitioning by way of Avalon components. How much more arbitrary do you want to become? For example, do you want to do something like this:
arbitrary_code --> Java class
Java classes --> component
components --> block
blocks --> application
Where you have four different ways of partitioning? That would seem not very arbitrary - the developer has to adhere to four different contracts and what if he needs a fifth partition?
Arbitrary partitioning to me would mean something like this:
arbitrary_code --> component
components --> component
While this is more elegant, because it has only one contract and the developer can be real arbitrary, it does not seem very useful to me.
cheers,
Ulrich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
