Re: New Jakarta proposal: Pluto

[Stefan Hepper]

Hi,
here some more answers to questions that arouse:

- Pluto is only the reference implementation for the Portlet API defined in the JSR 168
This is comparable with the tomcat being the servlet container and implementing the servlet API.
Pluto itself is only a infrastructure component. All portal related functionality like aggreagtion of the output of different portlets, authentication, etc. is NOT part of pluto, but needs to be provided by the portal calling pluto (e.g. JetSpeed or Coocon).

- Why is Pluto not part of JetSpeed?
Pluto has a very restricted scope and is an infrastructure componentet that can be used from serveral other projects (e.g. Cocoon and the proposed Charon). The Portlet API is defined by the JSR and cannot be changed and therefore differs from what you can do in JetSpeed, where you can freely define your API. I could easily see a situation where JetSpeed wants to provide additional functionality beyond the JSR 168 1.0. If these are different sub-projects this is easily possible: JetSpeed could just take Pluto and add functionality.

- Relation to other Apache projects:
JetSpeed and the Coocon portal framework plan to use Pluto (Carstten Ziegler just asked me to include him on the committer list).
As Portlets are Web components that may be bundled with other web components, like servlets/JSPs, Pluto will be build ontop of Tomcat.
Struts, JSF, and other web frameworks: Portlets sit in front of these frameworks. Each portlet can be viewed as a special web application that is rendered together with other applications on the same page. The portlet API provides the portal a standard way to call these applications. Each portlet is free to choose how to implement the logic and rendering inside: using JSPs, Struts, JSF, XML, ...


Regards,
Stefan


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>