Hello,
I have been talking with some guys on the Cocoon list,
specially Stefano, and would like to hear comments from
the Jetspeed people on a few issues. Stefano's comments
are quoted with "S>", mine with "G>", for clarity.
Please, let me state that I'm NOT trying to start a
flame war, or offend anyone. I'm just looking for a
clearer picture of things.
Let me explain up front that I have to build a bunch of
web applications that will finally interact with legacy
back-end systems, and have spent a few weeks perusing
several alternatives for this job. The applications will
very likely have a "portal" flavor, hence my interest in
Jetspeed.
S> > > > Turbine -> servlet (standalone)
G> > Besides being a servlet, it seems to define a standard way (sort
G> > of a "philosophy") for writing web apps, right?
S> Oh, yes, it's a framework, by itself doesn't mean anything
S> (more or less like Cocoon).
I guess what Stefano is saying here is that Turbine (and Cocoon)
don't do much by themselves; you have to provide your content
on top of them.
G> > How well does [Turbine] integrate (if at all) with Cocoon?
S> Unfortunately, it does not integrate and we have yet to discover a way
S> (if any) to do this. The projects are very different in both strategy
S> and design.
This is my very first concern: is Turbine a liability to Jetspeed?
I have been looking at Turbine for a few days now, and it strikes
me as a brittle design; there are two areas where this shows:
1. You can't CLEANLY have more than one application based on Turbine
running concurrently.
2. The basic page layout (top navigation, bottom navigation, etc.)
is dictated by the framework (please correct me if I'm wrong).
The Cocoon project has even gone as far as taking parts of Turbine
(like the DB connection pool) and integrating that into Cocoon. So,
it looks to me like Turbine is not perceived as a good generic app.
framework (at least by the Cocoon people). What are the thoughts of
the Jetspeed people in this regard? How heavy is the dependence of
Jetspeed on Turbine? If the mentioned deficiencies of Turbine were
never resolved, do the Jetspeed people see a clear migration path
to a non-Turbine version? Has this issue ever come up?
S> > > > Jetspeed -> based on *both* Turbine and Cocoon
G> > Ok, here I have my doubts: it seems to me that Jetspeed uses
G> > Cocoon as an API, something explicitly "forbidden" in the Cocoon
G> > guidelines. Is this correct?
S> Yes. Kevin Burton is fully aware of this and when Cocoon2 is ready the
S> Jetspeed project will fix this design flaw.
Do the Jetspeed designers agree with this assessment? If yes, how will
this "flaw" be "fixed" in the future? Do the Jetspeed people see more
opportunities of integrating Jetspeed and Cocoon in a framework-like
piece of software, designed to build web apps that have a portal flavor?
S> > > > Cocoon -> servlet and command line (based on Xerces,
S> > > > Xalan, Fop, Turbine-pool)
G> > Ok, here is the (to me) X million dollars question: if I were
G> > to build an application that:
G> >
G> > * is web based
G> > * has certain traits of a portal site (a la www.eurofootball.com)
G> > * uses XML to provide content, and XSL to present it
G> >
G> > and had to choose between all of the frameworks available
G> > (turbine, struts, xang [is this one even an alternative?],
G> > jetspeed, cocoon), which one should I use? Or, to put it
G> > more bluntly, which one would you, Stefano, use? 8-)
S> Jetspeed is cool but I don't like its current design.
I concur with Stefano: Jetspeed is VERY cool. Cocoon is also VERY
cool. I would love to use both, but don't perceive clearly yet where
each one's responsibilities and scope end. I would love to be able
to do something like this:
* A set of (concurrent) portals, each based on Jetspeed, each with
its own page layout, that integrate different sources of information
using the Jetspeed metaphor. The keyword, that seems to invalidate
Turbine (and hence Jetspeed) is "concurrent".
* Some (or all) of these portals can also be used to access web apps
written with Cocoon. Would the current design of Jetspeed be enough
to support this paradigm? I'm concerned with the fact that, is you
are running Jetspeed, you can't simply serve any XML content with
Cocoon, because that breaks the way Jetspeed handles some of its
content.
* All of this running on one (or more) servers, with just one instance
of each piece of software involved (Turbine?, Jetspeed, Cocoon,
auxiliary software such as Xalan, Xerces, etc.) installed on the
server. The basic server software will very likely be Apache + Tomcat.
I would love to hear any comments on these requirements and whether
they can be met today.
--
Gonzalo A. Diethelm
[EMAIL PROTECTED]
If this mail is in HTML format, blame Exchange Server: Q222508
