Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <38BA641A.D5F1383A@networks.vivendi.net>
Date: Mon, 28 Feb 2000 13:03:38 +0100
From: =?iso-8859-1?Q?Rapha=EBl?= Luta <luta.raphael@networks.vivendi.net>
Organization: Vivendi
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Cocoon2 and Turbine and Jetspeeed integration
References: <NCBBKKMPILBOFACAPHDDGEHJDPAA.gerard.van.enk@eo.nl>
 <38B87B51.8D99DFF0@apache.org> <38BA5383.FD3F954D@relativity.yi.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

"Kevin A. Burton" wrote:
> 
> Stefano Mazzocchi wrote:
> >
> > Yes. Both JetSpeed and Turbine are trying to incorporate Cocoon
> > capabilities into them... I think they can't possibly do this without
> > loosing much of the functionality, expecially the sitemap.
> >
> > So I'll push to go the other way around: reimplement JetSpeed on top of
> > Cocoon.
> >
> <snip>
> 
> Jetspeed isn't really a technology like Cocoon or Tomcat or anything.
> It is more just a place to take multiple projects and incorporate them
> into one framework (RSS and
> OCS/Messaging/Projects/iCalendar/Discussion/etc).  Avalon will be big
> there.  You can use Cocoon to drive Jetspeed 100% if you want.  It
> doesn't care.
> 
> Jetspeed really just sits on top of Turbine/Cocoon/Tomcat to provide a
> Portal.  This includes user subscription to multiple XML data
> sources/user authentication/ etc.  I am +1 at federating this out.  I
> was really strong at creating the Turbine project because most of the
> code would have had to be done within Jetspeed.
> 

I think the main contention point between Jetspeed and Cocoon is not in Jetspeed
but in Turbine, or to be more to the point the display processing
functionalities 
of Turbine.
However I don't think Jetspeed should be "re-implemented" on top of Cocoon, it 
should just offer 2 ways to drive its display:
- either through Turbine programmatic layout/screen/portlet incremental
rendering 
- or through Cocoon 2 global sitemap-processing filtering rendering

Both approaches have merits and cater to different working teams (Turbine 
being developper friendly whereas Cocoon is webmaster oriented) and different 
business needs (Turbine for web applications and Cocoon for content 
publication).

Even though a complete integration of Turbine/Cocoon would be very welcome, it 
really doesn't seem that easy so maybe a few bridges here and there would 
be enough for now... ;)

As Kevin said, Cocoon can currently be used for rendering in Jetspeed.
Cocoon should have a way to get more information on a content to be rendered
in order to fully leverage the forthcoming sitemap and I think that would be 
best implemented by using custom URLs in the sitemap and allowing external 
applications to add specific URLHandlers (more about this when it is clearer 
in my head...)
If we add to that an XSP taglib for accessing Turbine services, that would be, 
IMO, a decent start...

--
Rapha�l Luta - luta.raphael@networks.vivendi.net