Thomas, you wrote a lot there, I'd hate to see when you do 'dig into to
things deeply' ;)
see comments below....
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, January 10, 2001 1:21 AM
> To: JetSpeed
> Subject: RE: Jetspeed 1.3a2
>
>
>
>
>
> David,
>
> thanks for your comments. See responses below. Unfortunately, I was
> in a hurry because we currently have an urgent project, so I couldn't
> dig into things very deeply. We surely have to spend more time thinking
> of these topics, especially unification of service APIs and how to
> introduce the portlet instance ids.
>
> David Sean Taylor wrote:
>
> > > * Introduce Unique Portlet Instance IDs
> > >
> > > I think we also need to introduce a concept for unique portlet
> > > instance ids, maybe consisting of a user id, page id and portlet
> > > id and sequence number in order to be able to implement persistence
> > > services that store portlet data in a database. (This is just a
> > > first idea, maybe this a more complex topic.)
> >
> > Thomas, I ve been working with the persistence service that you
> > implemented. I now have it working with the new profiler, but there
> > are many issues still open for me. One is a way to uniquely identify
> > a portlet instance.
> >
> > I agree that we need a unique key to access a portlet instance based on
> > portlet and page.
> > The unique sequence number is also necessary for when you have the same
> > portlet referenced twice or more on a page.
> > Is the user id necessary, since the persistence info is stored
> in session
> > state associated with a user?
>
> The persistence service uses the session only as a write-through cache.
> The essential function of the persistence service is to store data like
> e.g.
> portlet settings in files (like the current default implementation) or in
> databases. To retrieve portlet settings, a query must be made to the
> database
> that includes <user id, page id, portlet id, sequence number>.
I agree.
>
> > One use case I've come up with is where a portlet needs to keep
> its state
> > across a session, for all pages in that session, and other
> times where it
> > needs to keep state for a particular page. The one use case I
> was working
> > with was for min/max/detach state, which by the way, Kevin already had
> > plans for if you read through the psml.xsd:
> >
> > <!--
> > The state defines whether the portlet should be shown in
> NORMAL mode,
> > MAXIMIZED mode, MINIMIZED mode or DETACHED. Not yet implemented.
> > -->
> >
> > <element name="skin">
> > <type>
> > <element ref="parameter" minOccurs="0" maxOccurs="*"/>
> > <attribute name="state" type="string" minOccurs="0"
> > default="NORMAL"/>
> > </type>
> > </element>
> >
> > Think about a common portlet that is used on all pages, such as a
> > Navigator. It will need to keep its state across all pages.
> > I see this portlet keeping its state in a 'session' scope. Actually, its
> > not even a portlet state but a controller state.
> >
> > What Im getting at is that persistence state may need to be on both
> > 'session' and 'page' - similar to (yet no exactly like) beans in jsp.
>
> I think that's a different topic. For handling that, we might introduce a
> PortletSession object into which portlets can put objects like a
> controller
> state, beans or whatever. This data does not need to be
> persistent, though.
> I agree that the user id is not required to access this data, as it is
> implicitly bound to a user by being stored in the user's session.
>
What if you wanted to remember min/max states across sessions?
So that the next time the user logs on, they page looks exactly the same as
before.
Im not sure why this should be a different kind of state.
Perhaps we need to more formally state the exact kind of state that the
persistence service is to manage.
> > Another thing I saw in the persistence impl is that a new persistence
> > service gets created for each portlet (or controller) that needs it per
> > page, and that it also stores the RunData internally, which I understand
> > is not a good thing to do, and I know the overhead of creating lots of
> > little services is not tuned for performance.
>
> The RunData usage definitively needs to disappear when we introduce the
> new portlet API. The concept behind the persistence service interface is
> to keep open how the actual implementation works. The we have provided as
> a start doesn't create new instances all the time. Each time you call the
> method for getting a service instance from the same session, you get the
> same service implementation object.
>
> > I guess that the each of these persistence service instances
> are meant to
> > only live for the duration of a request, took me a while to figure that
> > one out.
>
> The user (e.g. a portlet) of a service should obtain a service reference
> per request. Depending on the service implementation, this may be a
> reference to a new object for each call or a reference to the same service
> object all the time.
>
> It's up to service implementations to determine the life time of service
> objects. For the persistence service implementation we provided, the life
> time of the persistence service object conceptually is infinite (also the
> "physical" Java object lifetime of course ends with the session).
>
I dont want to dwell on the current persistence service impl.
Its obvious that its not final, and that the defining of the interfaces
should take precedence over it.
Actually your persistence service is working great for me in my tests for
persisting multiple pages with the new profiler.
It was just that in working with the service, I simply noticed the code
below being called for each portlet and controller who needed to get the
service per request ServiceFactory.getService:
if (aServiceInterface == PersistenceService.class)
{
service = new PersistenceServiceImpl ();
> However, for a location service that provides the current location, the
> conceptual lifetime may be the duration of processing one request, as at
> the time of the next request the location may be different if the user is
> moving, e.g. in a train.
>
> > Thats not how Turbine services work. I think it would be best if we
> > agreed on a common service paradigm, although Im open to another type of
> > service if necessary. I've noticed that we now have three:
> >
> > 1. standard Turbine services
> > 2. a kind of hybrid that Raphael and I started with: the
> > RegistryManagerService and ProfileManagerService -- which I like, but
> there
> > is a real problem with the way interfaces are duplicated
> > 3. the new Service and ServiceFactory defined in portal/service.
> >
> > -- David
>
> It would surely be good if we could unify the different service concepts.
>
> I think we should not directly use Turbine services for services that are
> basically extensions to the portlet API, like persistence, user info and
> location. This would tie the Portlet API to the JetSpeed implementation.
> The Portlet API has to be selfcontained and may only rely on J2EE, so that
> portals other than JetSpeed may implement the same API in a different way.
>
> Best regards,
>
> Thomas
>
> Thomas Schaeck
> IBM Pervasive Computing Division
> Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
> Address: IBM Deutschland Entwicklung GmbH,
> Schoenaicher Str. 220, 71032 Boeblingen, Germany
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
