cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neeme Praks" <>
Subject RE: Cocoon and Jetspeed
Date Thu, 08 Jun 2000 16:50:49 GMT

> -----Original Message-----
> From: burtonator []
> Sent: Tuesday, June 06, 2000 7:26 AM
> 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.

back again ;-)
ok, if we are here, then let's stay here...

> > 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 :)

ok, should do it more often ;-)

> 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 :)

yep, as always. I'm trying to give a helping hand here...

> 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 :)

no particular reason except for the one that I think my solution is more
flexible. Then again, there is the issue of performance... actually,
I've taken this up in the Jetspeed list so we'll see where we end up...

> 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.  

ok. isn't this implemented yet? I think I saw this in CVS...


View raw message