Pluto Project Intent

[Derek Richardson <De...@appiancorp.com>]

A while ago there were a couple of posts where one person (forgot who) said Pluto should be as feature-rich and scalable a container as possible, while someone else (also forgot who) said Pluto should simply be the RI and stop there.

My question: what is the intent of the committers? Which way will this project go? I'm betting that, since Pluto is being incorporated into JetSpeed2, that the answer is feature-rich and scalable; however, I'd like this clarified before we consider using Pluto in production.

Thanks.

Derek Richardson

Re: Pluto Project Intent

[Stephan Hesmer <sh...@apache.org>]

good points. we should add this to our TODO list and create a letter of 
intend.

Stephan


David H. DeWolf wrote:

> Derek Richardson wrote:
> 
>> A while ago there were a couple of posts where one person (forgot who) 
>> said Pluto should be as feature-rich and scalable a container as 
>> possible, while someone else (also forgot who) said Pluto should 
>> simply be the RI and stop there.
>>
>> My question: what is the intent of the committers? Which way will this 
>> project go? I'm betting that, since Pluto is being incorporated into 
>> JetSpeed2, that the answer is feature-rich and scalable; however, I'd 
>> like this clarified before we consider using Pluto in production.
>>
>>  
>>
> I'm not sure if there is total consensus on this yet, however, I do 
> think (correct me if i'm wrong) that we all pretty much agree that:
> 
> 1) The integrity of pluto as a reference implementation is a primary 
> concern. Implementing the specification takes precedence over all other 
> requests.  (Are there any documents that anyone has from Sun about 
> reference implementations and what they should/should not do).
> 
> 2)  There is a clear separation between the pluto container and the 
> portal driver.  The portal driver should not become any more than a 
> simple way to test the container/portlets. While it is possible (though 
> not decided) that pluto could become "feature rich".
> 
> My personal view is that pluto should evolve to be as feature rich and 
> robust as possible as long as it doesn't cause any questions for those 
> needing it as the reference implementation it is supposed to be.
> I think that Pluto should follow in the footsteps of Tomcat.  It's the 
> reference implementation of the servlet spec, however, it's also become 
> very robust.  For instance, it provides different Realm implementations, 
> it has Valves, it has an admin console).  While these aren't required by 
> the spec, they add value to the community.
> To me there are two kinds of value adds.  The first makes the app more 
> robust/scalable (Realms in tomcat).  The second makes it easier to use 
> (especially for those new to the technology) -(The Admin Console in 
> Tomcat is a good example).  Both of these types of value adds are good 
> in my opinion.
> 
> David
> 
>> Thanks.
>>
>> Derek Richardson
>>
>>  
>>
> 
> 
> 
> 

Re: Pluto Project Intent

[Martin Cooper <ma...@apache.org>]

"David H. DeWolf" <da...@vivare.com> wrote in message
news:40367BA8.1020104@vivare.com...
> Derek Richardson wrote:
>
> >A while ago there were a couple of posts where one person (forgot who)
said Pluto should be as feature-rich and scalable a container as possible,
while someone else (also forgot who) said Pluto should simply be the RI and
stop there.
> >
> >My question: what is the intent of the committers? Which way will this
project go? I'm betting that, since Pluto is being incorporated into
JetSpeed2, that the answer is feature-rich and scalable; however, I'd like
this clarified before we consider using Pluto in production.
> >
> >
> >
> I'm not sure if there is total consensus on this yet, however, I do
> think (correct me if i'm wrong) that we all pretty much agree that:
>
> 1) The integrity of pluto as a reference implementation is a primary
> concern. Implementing the specification takes precedence over all other
> requests.  (Are there any documents that anyone has from Sun about
> reference implementations and what they should/should not do).
>
> 2)  There is a clear separation between the pluto container and the
> portal driver.  The portal driver should not become any more than a
> simple way to test the container/portlets. While it is possible (though
> not decided) that pluto could become "feature rich".
>
> My personal view is that pluto should evolve to be as feature rich and
> robust as possible as long as it doesn't cause any questions for those
> needing it as the reference implementation it is supposed to be.
>
> I think that Pluto should follow in the footsteps of Tomcat.  It's the
> reference implementation of the servlet spec, however, it's also become
> very robust.  For instance, it provides different Realm implementations,
> it has Valves, it has an admin console).  While these aren't required by
> the spec, they add value to the community.

Not to be a damp squib, but I'd like to provide a sort of counter-example
from Tomcat.

One of the feaures introduced in JSP 1.2 was packaged taglibs, where
multiple taglibs could be contained in a single jar, and the TLD files need
not be made available outside the jar. This is great, because adding a
taglib to a web app involves just dropping the jar in the right place and
off you go.

Now, one of the features that Tomcat added beyond the spec (a long time ago)
was precompilation of JSP pages. This is great too, because it allows a
deployed application to start up and respond to requests quickly, rather
than making the first user wait for the pages to compile.

The catch is that precompilation does not work if you use packaged taglibs
(on Tomcat 4.x, which is the JSP 1.2 RI). And it will not be made to work in
4.x, because all of the developers are off working on 5.x now, and don't
seem to care. So the end result is that if I want to take advantage of some
of the cool additional functionality added to Tomcat, I need to give up some
of the cool functionality that was added to the spec for which Tomcat is the
RI.

Just a caveat to bear in mind while growing Pluto beyond a pure RI...

--
Martin Cooper


>
> To me there are two kinds of value adds.  The first makes the app more
> robust/scalable (Realms in tomcat).  The second makes it easier to use
> (especially for those new to the technology) -(The Admin Console in
> Tomcat is a good example).  Both of these types of value adds are good
> in my opinion.
>
> David
>
> >Thanks.
> >
> >Derek Richardson
> >
> >
> >
>
>
>

Re: Pluto Project Intent

["David H. DeWolf" <da...@vivare.com>]

Derek Richardson wrote:

>A while ago there were a couple of posts where one person (forgot who) said Pluto should be as feature-rich and scalable a container as possible, while someone else (also forgot who) said Pluto should simply be the RI and stop there.
>
>My question: what is the intent of the committers? Which way will this project go? I'm betting that, since Pluto is being incorporated into JetSpeed2, that the answer is feature-rich and scalable; however, I'd like this clarified before we consider using Pluto in production.
>
>  
>
I'm not sure if there is total consensus on this yet, however, I do 
think (correct me if i'm wrong) that we all pretty much agree that:

1) The integrity of pluto as a reference implementation is a primary 
concern. Implementing the specification takes precedence over all other 
requests.  (Are there any documents that anyone has from Sun about 
reference implementations and what they should/should not do).

2)  There is a clear separation between the pluto container and the 
portal driver.  The portal driver should not become any more than a 
simple way to test the container/portlets. While it is possible (though 
not decided) that pluto could become "feature rich".

My personal view is that pluto should evolve to be as feature rich and 
robust as possible as long as it doesn't cause any questions for those 
needing it as the reference implementation it is supposed to be. 

I think that Pluto should follow in the footsteps of Tomcat.  It's the 
reference implementation of the servlet spec, however, it's also become 
very robust.  For instance, it provides different Realm implementations, 
it has Valves, it has an admin console).  While these aren't required by 
the spec, they add value to the community. 

To me there are two kinds of value adds.  The first makes the app more 
robust/scalable (Realms in tomcat).  The second makes it easier to use 
(especially for those new to the technology) -(The Admin Console in 
Tomcat is a good example).  Both of these types of value adds are good 
in my opinion.

David

>Thanks.
>
>Derek Richardson
>
>  
>