Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: root@relativity.yi.org
Message-ID: <393C8B72.E2FC064C@relativity.yi.org>
Date: Mon, 05 Jun 2000 22:26:10 -0700
From: burtonator <burton@relativity.yi.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Cocoon and Jetspeed
References: <2ECFE9456D0F6A4FA77B38C25AAE230918FE@the.one.lv>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neeme Praks wrote:
> 
> As the discussion gets very Jetspeed specific, I'll move this to
> Jetspeed list now.
> Please make any further replies only to jetspeed list.
> 
> > -----Original Message-----
> > From: burtonator [mailto:burton@relativity.yi.org]
> > Sent: Saturday, June 03, 2000 3:35 AM
> >
> > > I've seen JetSpeed and like the idea very much, but it could be made
> > > _much_ simpler and more easily extended by using the full power of
> > > Cocoon2. Of course, not being available, this is something
> > > hard to do so Kevin doesn't have any absolute fault in this.
> >
> > +1024.  I need to be more active in this area but yes!
> 
> <snip>
> 
> > A large amount of features will use Cocoon 2.0.  There are many areas
> > within Jetspeed I am unhappy with.  Our next release (similar to the
> > Cocoon 2.0 blue sky) will fix these as well.
> 
> I'm glad to hear this. To find out this was the basic reason why I
> started this whole thread. I wanted to find out if the Jetspeed
> development is taking into account the Cocoon2 development. Now that I
> have learned this, I can sleep again at nights ;-)

Yes... it is :)

I need to become more active here.
 
> > Just a UI on top of PSML that is based on XSP.  The PSML would be
> > transformed into XHTML and would allow you to configure your own PSML
> > file.
> 
> > I don't like this ProjectX vs ProjectY format of this thread.
> >
> > Jetspeed will ALWAYS run with Turbine and Cocoon.  We won't be getting
> > rid of either one for any time soon.  Each has its advantage.
> >
> > Turbine handles the logic backend, Cocoon should handle the
> > presentation, Jetspeed should handle the data.
> 
> I think I'm somewhat responsible for the ProjectX vs ProjectY format of
> this thread and I apologise for taking it in this direction. It has been
> totally unintentional, I'm just trying to figure out how the different
> pieces of the puzzle fit together. And your vision is something I
> totally agree with, that's something I wanted to arrive at.

I think it is natural.  Each project wants to work in the most efficient
manner and therefore you sometimes get this vs. attitude.
 
<snip>
> > Yeah.  That would be me.  :) Read ./docs/TODO.  Cocoon 2.0 is great.
> > But you don't see me talking about Jetspeed 1.3 all the time
> > because the
> > code isn't done.  All these issues will be addressed.
> 
> I see many great things in TODO. However, I think there is also a
> shortcoming with the current development: too much effort is being put
> to developing actual applications of the Jetspeed framework without the
> framework itself being completed yet.
> Well, I'm not 100% aware, if this is actually the case, but this is just
> my impression. Probably I have this impression because I have different
> priorities concerning Jetspeed "core" features: it is more important for
> me to have a stable framework for building portlets and user
> personalization. Kevin, as I have understood, prioritizes more content
> management and related stuff and this is the strong side of the current
> Jetspeed. I'm not blaming Kevin for this, just expressing my view of the
> current weak point of Jetspeed. I'll try to help out in this area, as
> soon as I get comfortable enough with the current code base.

That is cool.  Blame me :)

I have tried to load balance the core and also implementing 'cool'
features.  I want to run Jetspeed as my own personal portal and this
means implementing features ahead of stability.  Hopefully 1.1.5 will
fix some stability/core issues.

I want user personalization, and a strong portlet env.  only a matter of
coding it :)
 
> To be more speficic, the first thing on my todo list is the possibility
> for a user to have more than one personalized page.
> This is a place where an XSP page instead of a static XML file could
> help out (but I'm not sure if it is an option at all). 

User customizablity can still be done without a DB on top of XSP.  I
want it to use Castor and then write the XML to disk.  In the future we
can have it write to a PSML provider which could be DB or filesystem

It can be done with XSP but I am +-0 for doing this in this manner.   Is
there any reason to do it this way instead of using my current proposed
mechanism?  ... which of course isn't implemented yet :)

> I will be digging
> deeper into Jetspeed code to understand how this could be achieved in
> the easiest manner (each user having a separate directory maybe?); maybe
> someone has some ideas on this / can give me some pointers in the right
> direction?

Right now the PortletFactory dishes out sets of Portlets and their
configurations.  This needs to be relagated to a provider/user mechanism
so that the Anonymous Turbine user gets default.psml and everyone else
gets USER.psml.  
 
> No hard feelings, just trying to help and put together the jigsaw puzzle
> about all these different projects in my head ;-)

-- 
Kevin A Burton (e-mail: burton@apache.org, UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org
Message to SUN:  "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme 
excellence consists in breaking the enemy's resistance without fighting.
    - Sun Tzu, 300 B.C.