> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> 
> Berin Loritsch wrote:
> 
> > I still disagree rather strongly with you.  Take a look at 
> J2EE.  Sun
> > wrote the specs and the compliance testing framework.  They 
> even have
> > a reference implementation--which I may add they do not 
> recommend for
> > prime-time.  The real J2EE systems are written by third parties like
> > JBoss, BEA, IBM, etc.
> > 
> > I don't see how having one super-container is going to 
> help.  I doubt
> > we would be able to come to one vision.  The fact that 
> consumers have
> > to choose between systems with largely overlapping functionality in
> > J2EE systems proves that consumers are intelligent enough 
> to find out
> > what their needs are.  What we need to do is provide enough 
> information
> > to help the consumer make their decision.
> 
> Sun designs a framework, so does Avalon.
> 
> Sun ships *ONE* reference implementation of that framework and allows 
> external entities to build other implementations.
> 
> Why should Avalon ship more than one reference implementation?

One point is that Sun has the following:

* A compliance test suite
* A reference implementation (not meant for deployment, just development)
* A specification document (actually more than one)

The other point is that we don't currently know what should go
into the reference implementation yet.  We have two containers that
are exploring two different approaches and focuses but have a large
amount of commonality.

We need to find the common points before we can create a unified
reference implementation.  We also need to know if the requirements
are real based on real usage.  Fortress is already used in several
locations including a proprietary app I wrote, and some written
by others.  Merlin is being used by Steve's company, and possibly
others.

Until we can develop the compliance test suite and the specifications,
we can't develop the reference implementation.  We can argue theory
until we are blue in the face, and then find out our design decision
is wrong.  Eventually we need imperical data that is only obtainable
through real code and real live use to substantiate our claims and
prove that the theory is really the best way.

We started talking about it a while back during Avalon 5 discussions.
In the end, we decided that for the time being it is best to pursue
the different implementations of Fortress and Merlin, and then merge
the good points of each into a better project.  That can't be done
until we know what the good points of each are.

> 
> Cocoon is also a framework.
> 
> Tell me: if Cocoon was shipping four different implementations of the 
> Cocoon internal interfaces for every time a new vocal 
> developer comes in 
> and doesn't like what the community decides, would that make it 
> perceived as a better project from the user community?
> 
> Think about it.
> 
> -- 
> Stefano Mazzocchi                               <[EMAIL PROTECTED]>
> --------------------------------------------------------------------
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to