cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <>
Subject Re: MailServerProcessor
Date Fri, 24 Dec 1999 18:39:30 GMT

Stefano Mazzocchi wrote:
> Brett McLaughlin wrote:
> >
> > Stefano Mazzocchi wrote:
> > > > Now, the real questions, is this worth pursuing?
> > >
> > > The idea? totally. Something like this in Cocoon? don't know, maybe not.
> >
> > +1 for it being useful.  -1 on it being in Cocoon (at least the core).
> >
> > I see two options:
> >
> >  (1) Make it part of Jetspeed, where it sort of belongs
> >  (2) Create a cocoon-extra type structure where things like this (and
> > OWSKiller, etc.) can live for extra download, but not part of the core
> > Cocoon package
> these are orthogonal, it's not an "aut aut" situation.


> > > > Would this be in competition to what JetSpeed is doing?
> > >
> > > I would think so. This is the way JetSpeed should work.
> >
> > Jetspeed is a little strange.  It is _supposed_ to be built on Turbine,
> > and use Cocoon (part of why yours truly slaved away on that interface to
> > Cocoon).  But Kevin stopped work on it altogether a while back, and then
> > did some work on Turbine user admin.  Then he stopped that.  Now I have
> > no idea what he is doing.  But Jetspeed is _exactly_ the sort of
> > application that should use this sort of thing.
> If Jetspeed doesn't go anywhere, we make it go where we like it's the
> best, right? No need to fork development.

Yes.  Here is how I see it.  Cocoon is a web publishing framework, and
should do _that_.  Period.  That's why things like LDAPProcessor and
OWSKillerProcessor and MailProcessor are excellent tools, but not part
of core Cocoon.  They are parts of applications (consider them
application modules) that _use_ Cocoon for publishing.

Turbine is the OSS application framework of choice.  If you are going to
use a "framework thingie" (for Donald ;-) ), which if you are writing a
web application, and not just a web site, you should be using.  It takes
care of so many important details in web applications that Cocoon does
not and should not have to worry about... authentication, application
module "pluggability", database connectivity, and soon XML-RPC wrapping,
to name a few.

Jetspeed _should_ be a "refernce implementation" of the _right_ way to
do J2EE.  IE, using XML and eventually XSP, using Turbine, using EJB,
using servlets, *not* using JSP (why do it just because it's there?),
and _using_ Cocoon.  This is where we put together an amazing
application/portal/groupware thing that shows off all these great toys
we have.  So we build it on Turbine, we use all these new features
Cocoon has, like the LDAPProcessor and the MailProcessor, and we blow
people's minds.  That's the way I see things lining up.  I hope in a few
weeks when Cocoon and Turbine settle a bit, lots of people here come
over and help on Turbine, and then Jetspeed.  It really shows people
what this stuff can do.  Heck, Stefano, we can even look at using some
Avalon design patterns if you think they are appopriate.  I'm open to

> ------------------------- http://ApacheCon.Com ---------------------

View raw message