On Tue, 21 Jan 2003, Costin Manolache wrote:
> Date: Tue, 21 Jan 2003 11:31:32 -0800 > From: Costin Manolache <[EMAIL PROTECTED]> > Reply-To: Jakarta General List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: New Jakarta proposal: Pluto > > Alex McLintock wrote: > > > At 17:41 21/01/03, you wrote: > >>One more question: why not doing this as a subproject of JetSpeed ? > >>It is an existing jakarta project, the scope matches - why > >>creating a separate jakarta community instead of joining the > >>existing one ? > > > > > > I assume that it would be a tool which could be used by the Cocoon portal > > system, and a Struts portal system as well as Jetspeed which is > > essentially a Turbine portal system. People may want to use this component > > without using Jetspeed. Of course I haven't read the JSR yet. > > My understanding was that Jetspeed goal is to implement a portal - with Java > and XML. > > I would rather see all portal systems sharing a single community and > implementing similar behavior/standards - rather than have one portal for > each technology ( struts, cocoon, turbine, tapestry, plain JSP, plain > servlet, whatever else toolset ). > One thing to remember is that JSR-168 is only standardizing the interface between a portal server and the portlets it calls (just as the servlet spec only defines the interface between a servlet container and the servlets). The architecture of the portal server itself (or the servlet container itself) is not being mandated. Therefore, it's entirely reasonable to have a single portal server implementation (created with whatever server-side technologies the developers of the portal server choose). But it's also reasonable to have different portal servers with different feature sets, aimed at different markets, if that is what folks want to do. But, as Costin says, that should *not* be driven by the technology used to implement the portal server itself. Where the frameworks need to get on board, IMHO, is making it easy to create standard *portlets* using that framework's technology -- that way, someone who wants to deploy a portal is not constrained to only using web components implemented on a single particular framework. And portlet-based Struts applications (for example) could be plugged into anybody's portal server as long as it supports the standard portlet API. > Costin Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
