Pete Carapetyan wrote:
> To summarize a dozen or so emails on the one container versus many
> approach and why each is the only way, there is no resolution.
>
> But there is no need for resolution, and here is why, or at least if I
> am understanding it correctly.
>
> Let's say we were all Tomcat guys instead of working on Avalon.
>
> If we had a default Tomcat, one just like the one now, everything
> would be fine.
>
> Then, we could still have microTomcat
> and embeddedTomcat
> and a special cocoonTomcat
> and a sandboxTomcat
> and anything else we wanted, and the market would not see it as bad,
> nor as a dilution of the brand.
>
> The other Tomcats would probably be mostly ignored, but that is OK.
>
> Just so long as there was one real banana. One Tomcat that always
> worked the best, always was the default, etc. Just like the current
> Tomcat !
>
> So you can have your cake and eat it too. Just have a default
> container, one with everything, that does everything, one that follows
> all the rules. Lesser or special purpose containers wouldn't hurt a
> bit. You might want to hide them from the main pages a bit, but that
> is a different matter.
I'm totally with you here - except for one point. If you rephrased the
above so that the default container is the reference implementation
(RI), set's the standard for any container - but "does not do
everything" - then I think we have something better than Tomcat. We have
the ability to add the container functionality when and where we need
and if we can assume that variant containers are based on a strict
container validation test-suite - then the user does not care about the
container.
Assume that anything that passes the test-suite must run in a kernel. If
you look at this with the pricipal of kernel and container separation -
then the user end up saying - ok - here is the kernel, here is some
container (I don't care which container because it no longer matters)
and I drop the container onto the kernel and it runs - guaranteed -
every time.
Cheers, Steve.
>
> Because the only thing that is hurting Avalon right now is not knowing
> which one to use, and not having one that is most perfect. Otherwise,
> choice is not bad, just shows how powerful Avalon can be. Or at least
> that is the way it seems to me.
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
