portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SCHA...@de.ibm.com
Subject Re: [VOTE] Portlet API, Results of the Chat
Date Sat, 03 Mar 2001 10:36:46 GMT



Some additional info on two of the questions.

Santiago Gala wrote:

> > 2. Should the session object be passed as separate object of the
> > Portlet.service() method?
>
> -0. I think we should either go with a
> service(request, response) model ---> Portlet implements servlet,
> PortletRequest implements ServletRequest
> so that a servlet can be used as a portlet by the container, or a
> getContent(data) model ---> RunData encapsulates all objects

The question should be:

"Should the service method be similar to the Servlet API's,
service method i.e. service(PortletRequest req, PortletResponse rsp)
or should we deviate by providing the session as a third parameter ?".

As one fundamental concept behind the new Portlet API to be as
similar as possible to the Servlet API, the IBM position is of
course that the service method definitively should *not* have the
session as a third parameter, the session should be obtained from
the request just similarly to the Servlet API.

(By the way, this avoids problems when running on a cluster using
sessions that are persisted to a database - creating the session
object in this case would mean to get the serialized session object
from the database, deserialize it and instantiate the session object.

Obviously, it is advantageaous and simple to only do this when the
portlet calls portletRequest.getSession(), i.e. when it is really
needed rather than getting the PortletSession object from the
HttpSession object in the session persistence database and passing
it through the third parameter for each request.

One might think it may be possible to use a lazy PortletSession
object that only does the database object when e.g. it's
getAttribute methods are invoked, but even to only determine whether
a PortletSession object or a null pointer should be passed through
the service method would require to access the persistent session DB,
deserialize the HttpSession object, look into the HttpSession object
whether there is a PortletSession object prefixed with the portlet's
ID. From this perspective, it does not even seem feasible to
explicitly provide the session as a third parameter of the service
method.)

> > 4. Should we stick with the attribute getters/setters from the
> > Servlet API or use the DynamicData object consistently across the
> > relevant objects (request, session, configuration, user, page)?
>
> This goes up to my comment to (2). I think the crucial item is
> deciding if we go for a overloaded (and with further semantics)
> "standard" servlet call, or if we have a request model similar to
> the one in Turbine. Once we have this top level idea clear, we can
> proceed. Mixing both in the model will be a mess.
>
> I don't have a clear position on this one. Having the first model
> allows for straight integration of existing servlets (at the cost
> of more processing, cause they would deliver full documents). Having
> the second model means a new API to define (based on the one in Turbine),
> and maybe a cleaner interface.

You've exactly got a good point here.

(As the guiding principle for the design of the Portlet API was to be
very close to the Servlet API, the IBM position is to stick with the
getters/setters.)

>
> > 5. Do we want to stick with a pre-defined set of capabilities.
> > Preferably not, but if the names of capabilities are standardized,
> > how is the portlet going to find out whether a particular capability
> > is present?
>
> We can have a mechanism similar to the one in TRAX:
> the portlet can ask for an Iterator on capability names.
> the portlet can ask for the value of a capability.
> the container can throw an exception if it ignores the capability name.
>
> This allows for futurer extensibililty. We define a minimum set of
> required and optional capabilities supported in the version 1.0 of
> the spec.
>
> > 6. What should be the interface of the user?
>
> I don't understand the question here. Which interface? who is the user?
>

Best regards,

Thomas

Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479   e-mail: schaeck@de.ibm.com
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany



Mime
View raw message