portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject RE: Simplifying Pluto: Pluto 1.1? (was RE: Defining the release)
Date Thu, 07 Oct 2004 13:42:33 GMT

I appreciate your candid feedback. As you clearly stated, Kuiper, while it
does have it's issues, IS much easier to embed with a portal.  I believe
that this is a direct result of the fact that it was designed from the
ground up for that specific purpose and uses standard programming practices
and design patterns to accomplish that goal.

I'd encourage you to take a hard look at the 1.1 seed code (at this rate it
looks like it'll be a 1.1 branch) which I'll be uploading in the next day or
two.  The seed code is also intended, from the beginning, to be much easier
to embed.  Additionally, I think you'll find several distinct advantages
over Kuiper and honestly believe that you'll like it even better that Kuiper
if you take the time to take a quick look at it.  

Additionally, all indications show that this upcoming seed code will have
community buy in, something Kuiper never was able to get.  This in itself
will ensure that it will grow and become more than just one man's whim of


> -----Original Message-----
> From: David Barral [mailto:david@elrincondelprogramador.com] 
> Sent: Wednesday, October 06, 2004 5:54 AM
> To: pluto-dev@portals.apache.org
> Subject: Re: Simplifying Pluto: Pluto 1.1? (was RE: Defining 
> the release)
> Hi.
> I am one of the couple and I can't agree with David this time.
> As Jason Novotny said in the "Re: Simplifying Pluto: Pluto 
> 1.1? (was RE: 
> Defining the release)" thread, the current Pluto is awfull to 
> work with. 
> Too much complexity, too much interfaces. Even with the 
> latest changes 
> it still seems to be a better aproach to build your own container or 
> seek for a better one. And that's no big deal for the reference 
> implementation (Sorry for being rough).
> I don't know the details but it always seemed to me that 
> Pluto came from 
> a previous source that was more than messy.
> "One thing I've realized while going through that process is 
> that a lot 
> of the bloat in the current Pluto version is due to trying to provide 
> what I would consider too much flexibility". I agree, but you 
> can obtain 
> flexibility without that much complexity.
> I'm sure that it's a bad idea to improve something that's 
> wrong from the 
> beginning. Maybe David has done a wonderful job improving and 
> simplifying the current Pluto but Kuiper was far lot better than the 
> original Pluto (the TOTAL reovolutionary approach was extremely 
> necessary). Altough it lacked some JSR-168 functionalities and some 
> things could be improved a lot (like timeout handling, caching 
> facilities, Render state support, etc), it was a nice 
> codebase to work 
> with. I'm going to work with it whatever happens with Kuiper. 
> Even if no 
> one else supports it. Currently is't easier for me to integrate this 
> container and once our framework works nice switch to another 
> container.
> Maybe Kuiper shoud become a different project apart from Pluto,  but 
> this should only double the effort.
> Regards.
> David.
> David H. DeWolf wrote:
> >>Nick Lothian wrote:
> >>
> >>
> >>I believe someone (David?) started on a Picocontainer based 
> >>version a while
> >>ago.
> >>
> > 
> > 
> > True.  It is under the sandbox and called kuiper.  I think 
> that a couple of
> > people had found it useful and actually had leveraged it 
> for several things,
> > however, now I'm of the opinion that pluto's next 
> generation should rely
> > more heavily on some of the techniques which pluto-1.0.1 
> utilizes while at
> > the same time refactoring it into a much more manageable
> > architecture/design.  Kuiper on the other hand took a TOTAL 
> revolutionary
> > approach which I no longer think is necessary.
> > 
> > I have just proposed adding seed code for the next 
> generation.  The seed
> > code is based off of pluto-1.0.1 but uses some of the 
> design decisions which
> > made kuiper simpler to embed.
> > 
> > It may be time to purge kuiper from the repo.
> > 
> > David
> > 
> > 
> > 
> -- 
> /**
>   * David Barral
>   * MyPersonalizer Team 
> [http://www.tic.udc.es/~fbellas/mypersonalizer]
>   * david@elrincondelprogramador.com
>   */

View raw message