Stefan Hepper wrote: > - 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).
Well - tomcat implements servlet API and JSP, but technically it is not the actual reference implementation, it is used in the RI ( J2EE RI AFAIK is considered the RI for servlet/JSP ). And tomcat implements a bit more than just jsp/servlet - it has admin interface, CGI and SSI support, WebDAV and its own extension APIs. Same can be said about most other projects that implement APIs ( xerces, xalan, axis, etc ). > - 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. The API defined in a JSR can't be changed - period. Jetspeed can't take pluto and modify some APIs if he wants to - that would be wrong and against the JSR rules. If Pluto community decides to provide additional features, like integration in cocoon/struts/etc - I don't see what would stop it and why this would be a bad idea. Maybe my question was wrong - the problem is why Pluto and JetSpeed ( and other portlet efforts ) are not in the same community ( with a single portlet related mailing list ) ? > - 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, ... I would preffer that all portlet-related technology would be in the same project and community, with JSP/struts/cocoon specific areas. Maybe an "commons"-like project. Please don't treat my questions as oposition to Pluto proposal - I think it's a good thing and I would be happy to see it in Jakarta. I just think it would be better for pluto and portlets in general if a bigger community would be around it and all rendering frameworks would cooperate ( at least in support for portlets ). That could result in a consistent portlet support, or at least some sharing of ideas - and get enough review to whatever happens there. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
