Ulrich Mayring wrote:
Leo Simons wrote:
Ulrich Mayring wrote:
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.
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 :)
OK - I ready to take you up on that :-)
1. i hate �ber-container - its missleading
2. profile based container solution based on a common architecture
is a much more useful description
3. we can deliver strong webservice support providing we are ready
lift an Avalon lock-in mentality, and instead, embrace the abstract
concepts of deployment strategy, assembly, lifecycle, lifestyle, etc.
4. backed by a rock solid implementation of the Avalon component
model
And none of the above is fantasy - its all based on validated code.
Now, if we prove you wrong are you ready to streak across the Cocoon
list wearing nothing but a Avalon cap and big grin?
:=)
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.
You don't need give up anyting.
See below.
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.
How about:
manages
|--------------|
V |
arbitrary_code --> component ---> container
^ |
|is a |
|--------------|
Cheers, Steve.
cheers,
Ulrich
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
