RE: Simplifying Pluto: Pluto 1.1? (was RE: Defining the release)

[Nick Lothian <ni...@essential.com.au>]

I believe someone (David?) started on a Picocontainer based version a while
ago.

I'd prefer Spring, but that's just because I have more experience with it. 

(Speaking of Spring - I recently submitted some patches so allow you to use
Spring MVC - including the Spring taglibs - in a Portlet. See
http://opensource.atlassian.com/projects/spring/browse/SPR-317 for a sample
of how to use it.)

Nick

> -----Original Message-----
> From: Scott T. Weaver [mailto:scott@binary-designs.net]
> Sent: Thursday, 30 September 2004 11:41 PM
> To: pluto-dev@portals.apache.org
> Subject: Re: Simplifying Pluto: Pluto 1.1? (was RE: Defining the
> release)
> Importance: Low
> 
> 
> Has there been any discussion on possible technologies to 
> build Pluto1.1 
> upon? Spiring Framework, Pico/Nanocontainer? The current factory and 
> factoryfactory stuff in Pluto is just downright awkward to 
> work with. I 
> think basing Pluto on a simple IoC framework would be a great 
> place to 
> start.
> 
> FWIW We started down the Pico/Nano/Groovy route with Jetspeed 2. 
> However, after some exposure to Spring, we decided very 
> quickly that it 
> (Spring) was a far more mature, stable and easy to use as a IoC 
> framework than the Pico/Nano/Groovy combination.
> 
> If this is of interest I would be more than happy to dedicate time to 
> getting Pluto 1.1 rolling with Spring.
> 
> David H. DeWolf wrote:
> 
> >>Could we have two streams - a 1.0 stream in which the 
> interface won't
> >>change, and a 1.1 which will have a changing interface?
> >>    
> >>
> >
> >I'm (obviously) very interested in pursuing this.  I would 
> like suggestions
> >on how this would logistically be done?  Do we branch the 
> codebase with a
> >1.1 branch and just start?  If so, does anyone have enough 
> experience with
> >svn to do it?  Or, do we need to whiteboard several approaches in the
> >sandbox and then vote on which one to take?  I'm ready to 
> get going, is
> >anyone else interested in going along this path with me?
> >
> >When we do start down this path, I would be interested in 
> the opinions of
> >the originators of pluto and also VERY interested in the TCK.  Also,
> >hopefully other embeders would be actively involved in the process.
> >
> >David
> >

RE: Simplifying Pluto: Pluto 1.1? (was RE: Defining the release)

["David H. DeWolf" <dd...@apache.org>]

David,

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

David





> -----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
>   */
> 

Re: Simplifying Pluto: Pluto 1.1? (was RE: Defining the release)

[David Barral <da...@elrincondelprogramador.com>]

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
  */

RE: Simplifying Pluto: Pluto 1.1? (was RE: Defining the release)

["David H. DeWolf" <dd...@apache.org>]

> 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