cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon2 Design
Date Fri, 02 Jun 2000 14:50:41 GMT
David Duddleston wrote:
> 
> > > > Well, ECS could be updated to return SAX events.... but then you must
> > > > make Turbine aware of SAX and make it a generator.... so if you do, it
> > > > becomes an XTurbine :)
> > >
> > > ;-)
> > > And this is almost the target we are aiming at... but I think it will be
> > > easier just to take parts of Turbine and integrate them to Cocoon that
> > > to rewrite whole Turbine into XTurbine (and the end result would still
> > > be even bigger hack than now).
> 
> I agree. It is easy to forget that Turbine is a Framework which works for a
> certain set of needs and programming styles, just as Cocoon does. Why bother
> changing it.

totally agree.
 
> Turbine has some base services like form based authentication and
> authorization, connection pooling and other various utility classes the
> expedite the development of Web Applications. Yes, it would be very nice to
> use these same services in Cocoon as well. Considering the direction of
> Cocoon 2 which to me seems like it will be playing the primary Web
> Application role as in "I call you" instead of "You call me" <-- Stefano's
> words,  then it would make even more sense that Cocoon should provide basic
> services and utility classes that the majority of Web Application will need.
> It is not an absolute, but seemingly logical.

ditto
 
> The real trick it is to get collaboration between the different projects
> (Turbine, Cocoon, JetSpeed, Avalon, Struts...) to share service/utility
> related classes, but that has been a real losing battle over the last year
> or so. 

Unfortunately yes. But see my comments below...

> I have seen it proposed over and over, but not much ever comes of it
> for various reasons. Not to say that there has been no progress in that
> direction, JetSpeed was reimplemented to run on top of Turbine (then Dash)
> instead of going completely off on it's own, it seems there has been some
> steps taken between Avalon and Cocoon to share some classes and concepts,
> and James being built with Avalon. Actualy, there has been some good
> progress.

I can't talk for JetSpeed, Turbine or this Craig's new "Struts" since I
don't have one of my million feet in there :) but Avalon, Cocoon and
James all share the same ideas and integrating them would be "piece of
cake".

And you can quote me on that any time you want.

I was hoping Federico would get a burst of development now that Exoffice
sponsors him on his Avalon/James work, but I didn't see it happening...
probably I need to be around to wake him up (and Pier, his housemate, is
not always around to do it).

Well, I can't tell you "when" but the design issues involved are simply
too big... the problem with Avalon is that it's a meta-framework. It's
more abstract than people can normally get.

Many said to me: they seem lotsa good ideas, but what does it mean for
my code?

So James was designed to "show" the power of Cocoon, but Federico was
left almost alone doing it.

Gee, I just wish I had more than 24 hours a day...

> On the other hand there is a strong aurgument of having multiple projects
> that are decentralized with the ability to incubate ideas and concepts
> without having to conform to any sort of standards or guideline created by
> other projects.

Yes and no. Avalon engineers componentization patterns. Cocoon
engineered separation of concerns. Your application should use both.

The very final goal (probably in 2010 or something :) is something like
this

         +-> Cocoon 
         |
 Avalon -+-> Tomcat 
         |
         +-> James
         |
         +-> ???

where you can make a web application (tomcat) with XML (cocoon) that
generates a SVG graph of the number of mails (James) sent to your
mailing list on a daily basis.

Also, creating each server as a collection of components that can be
reused as they are (logger, object store, thread manager, database pool,
authentication store, XML parser, XSLT transformer, RDF analyzer,
etc....) by the other servers.

All running on the same JVM or on different instances, all will the
ability to "add" your components just as easily, and to extend each
server functionality with servlets, mailets or Cocoon pipeline
components, war files, JSP and what else you want to add.

Integration is the goal.

But we can't possibly do all this overnight. It's a slow process and
needs everyone to agree on the designs.... not an easy thing.

> I think there is some happy middle ground here that can be achieved, but it
> would take several highly motivated people and some open minds by those
> leading the various projects to make it happen.

I'm highly motivated and I'm sure any of you is, as well.

It's only a matter of pushing for the right direction and have patience.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message