Objectives for Pluto / Jetspeed 2 portal services

[Serge Huber <se...@jahia.com>]

Hi all,

Please excuse the newcomer question, but I am not very clear as to where 
the seperation between Pluto and Jetspeed will be. I see a lot of people in 
the Pluto mailing list discussing features which I think should really be 
left at the portal layer than the portlet container level. So this brings 
the question : is Pluto supposed to contain a portal at all ? I know there 
a sample portal implementation, but now that it is open sourced it might be 
tempting to expand on that, and therefore sorta have a "concurrent" 
implementation to Jetspeed 2.

I'm not trying to heat anything up, I'm just trying to understand where 
people stand on this issue. Is Jetspeed 2 supposed to be the "main" portal 
implementation for Pluto, or will Pluto keep offering portal services ?

As for where I stand, I think Pluto should be kept as close as possible to 
the implementation of the container itself, by staying as embeddable as 
possible with Jetspeed 2 but also other portals if interesting. The 
seperation will probably be an exercice in design itself ?

Regards,
   Serge Huber.

Re: Objectives for Pluto / Jetspeed 2 portal services

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

Hi Santiago,

> 
>> Pluto will not offer portal services, only the services that fall into 
>> the container domain. I'm strongly for keeping portal and container 
>> seperate. A portlet container should be callable from different 
>> portals (e.g. jetspeed or WSRP4J).
>>
> 
> +1
> 
> If we don't go this way, we will loose a lot of what we are winning with 
> JSR-168, i.e. decoupling between container, portal and portlet 
> Applications.

+1

I totally agree. We need to decouple this.

> 
> In doing so, in addition, we are starting the process for having a "de 
> facto" standard for container <-> portal API, which I think is an 
> interesting exercise.

interesting point. yes, we definitely can gather experience with pluto
about this API. I also think, that this iwll give use valueable 
information that might go into another standard some time in the future.
Aso long as there is no we have the "de facto" standard from pluto.

> 
> This API should evolve here, but should be managed carefully by pluto 
> community. This will help a lot portals interested in plugging into 
> pluto (as opposed to developing their own container) to avoid moving 
> targets and redesigns.

+1

we as the pluto community need to carefully look inot this topic to 
ensure this. I am glad we all think along the same lines here :-)

> 
> Jetspeed is *just* one of those portals.
> 
> What do you think?
> 
> Regards,
>      Santiago
> 
> 

Regards,
     Stephan

Re: Objectives for Pluto / Jetspeed 2 portal services

[Santiago Gala <sg...@hisitech.com>]

El lunes, 13 octu, 2003, a las 10:02 Europe/Madrid, Stefan Hepper 
escribió:

> Pluto will not offer portal services, only the services that fall into 
> the container domain. I'm strongly for keeping portal and container 
> seperate. A portlet container should be callable from different 
> portals (e.g. jetspeed or WSRP4J).
>

+1

If we don't go this way, we will loose a lot of what we are winning 
with JSR-168, i.e. decoupling between container, portal and portlet 
Applications.

In doing so, in addition, we are starting the process for having a "de 
facto" standard for container <-> portal API, which I think is an 
interesting exercise.

This API should evolve here, but should be managed carefully by pluto 
community. This will help a lot portals interested in plugging into 
pluto (as opposed to developing their own container) to avoid moving 
targets and redesigns.

Jetspeed is *just* one of those portals.

What do you think?

Regards,
      Santiago

Re: Objectives for Pluto / Jetspeed 2 portal services

[Stefan Hepper <st...@hursley.ibm.com>]

Hi Serge,
Pluto is the reference implementation of JSR 168 that defines a portlet 
container. Pluto is per se not coupled to Jetspeed, but provides a 
container implementation that can also be used by other projects. In 
order to pass the TCK for JSR 168 (and therefore be compliant with JSR 
168) you need to have some portal driver, as the JSR 168 currently not 
defines any interface between the portlet container and the portal that 
the TCK coul d leverage. Therefore I think the portal driver is needed 
in pluto.

However, I agree that people are tempted to enhance the pluto portal 
driver, which I think is the wrong way to go. If you need a full portal, 
not just a container to run your JSR 168 portlets for testing, you 
should take jetspeed.

Pluto will not offer portal services, only the services that fall into 
the container domain. I'm strongly for keeping portal and container 
seperate. A portlet container should be callable from different portals 
(e.g. jetspeed or WSRP4J).

Regards,
	Stefan

Serge Huber wrote:
> 
> Hi all,
> 
> Please excuse the newcomer question, but I am not very clear as to where 
> the seperation between Pluto and Jetspeed will be. I see a lot of people 
> in the Pluto mailing list discussing features which I think should 
> really be left at the portal layer than the portlet container level. So 
> this brings the question : is Pluto supposed to contain a portal at all 
> ? I know there a sample portal implementation, but now that it is open 
> sourced it might be tempting to expand on that, and therefore sorta have 
> a "concurrent" implementation to Jetspeed 2.
> 
> I'm not trying to heat anything up, I'm just trying to understand where 
> people stand on this issue. Is Jetspeed 2 supposed to be the "main" 
> portal implementation for Pluto, or will Pluto keep offering portal 
> services ?
> 
> As for where I stand, I think Pluto should be kept as close as possible 
> to the implementation of the container itself, by staying as embeddable 
> as possible with Jetspeed 2 but also other portals if interesting. The 
> seperation will probably be an exercice in design itself ?
> 
> Regards,
>   Serge Huber.
> 
> 
>