RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols

[Thomas Schaeck <SCHAECK@de.ibm.com>]

I also think that both templates (if suppoerted by a particular service)
and instances need to be persistent, with a 1:n relationship between
templates and instances.

In many cases, persistent instance state will be modified by users or by
portal administrators on behalf of users via the WSPR services UIs (edit
mode).

Persistent template state (if a service supports the template concept) will
typically be modified by portal administrators, since that is what defines
portlets that then can be taken by users or administrators and put on
pages, creating instances.

Transient session state is on a per-user/per-session basis, theoretically
the same user might run multiple sessions to a service at the same time
(e.g. from PC and WAP Phone if the service supports multiple devices)

An example: Mail Portlet

Persistent Template State (modifyable via WSRP service's UI (config mode)
or exposed properties)
- Maximum mail file settings
- Basic settings, default font sizes, colors, ... defined by administrator
on behalf of users

Persistent Instance State (modifyable via WSRP service's UI
(edit/personalize mode))
- Fields to be displayed
- User's favorite font size
- User's favorite color

Transient Session State
- location in the dialog flow the user has reached
- other data relevant across requests

Best regards,

Thomas


Eilon Reshef <eilon.reshef@webcollage.com> on 04/12/2002 04:31:14 AM

Please respond to Eilon Reshef <eilon.reshef@webcollage.com>

To:    "'Sasha Aickin'" <AlexanderA@plumtree.com>, "'WSRP'"
       <wsrp@lists.oasis-open.org>
cc:
Subject:    RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols




Sasha,

I see your point.

I assume that in this scenario, the preferences are  persistent... does it
make sense in this case to say that there are two ways to  look at the
use-case then, one is that the user is essentially  editing the portlet
template, which is the persistent entity,  and naturally next time around
the portlet instance will be created based on the  new template, or
alternatively, that the user is editing the portlet  instance, and parts of
it are persistent.

I guess my possibly over-simplistic thought was that we  can try to
associate portlet templates with the persistent state and portlet
instances with the transient state (all of which is regardless of the
question  of where the persistent state is stored).

Eilon
-----Original Message-----
From: Sasha Aickin  [mailto:AlexanderA@plumtree.com]
Sent: Thursday, April 11, 2002  9:48 PM
To: WSRP
Subject: RE: [wsrp] Divide-and-Conquer  Interfaces-and-Protocols


Eilon,

I  basically agree with what you say here, with the following  caveats:

Portlet instances that are personalized do not have as clear a  distinction
between run-time and design-time as those without  personalization.� For
example, an e-mail portlet may have a  personalization page that asks what
fields the end user wants to see (sender,  received date, etc.), and this
personalization should be accessible at any  time.� An end user who sets
these kinds of personalization preferences is  performing desing operations
on the portlet instance.

Does  this make sense?

Sasha.
-----Original Message-----
From: Eilon Reshef  [mailto:eilon.reshef@webcollage.com]
Sent: Thursday, April 04,  2002 9:17 PM
To: 'WSRP'
Cc: 'Michael  Freedman'
Subject: [wsrp] Divide-and-Conquer  Interfaces-and-Protocols



One random thought on a  way to divide-and-conquer the work around
interfaces and protocols around  the timing of the protocol/interface
invocation, i.e.,  one of  two:

Some things happen in  run-time, assuming the portal page is already well
defined  and configured (in our terminology, there's a portlet template
that's  already completely configured), and an end user comes to the page.
Under  this category fall all the issues with regards to the portlet
instance: rendering of the portlet page, action/events/getContent,  URL
rewriting, user identification, and so on.

Some things happen in  design-time, assuming that a portal designer or an
administrator is working to configure the portlet and/or the portal page.
These issues deals mainly with the portlet template:  find/bind, interface
discovery, copy/clone, portal identity, and the  workflow around
administrating the template data.

This is not to say that from a  workflow perspective, there couldn't be
interleaving steps of run-time and  design-time. For example, an
administrator could set up a portlet and use  its "admin" mode (which
itself employs a portlet instance) to configure some  template settings
(although at this stage the template is not  "end-user-ready" yet), then a
portal designer sets more template settings,  and so on, until eventually
the template is exposed to the end  user.

A couple of reasons why this  categorization may be relevant is because the
design-time considerations  seem to be pretty specific to portals whereas
the run-time considerations  seem to overlap more with WSIA and may require
more collaboration with  WSIA.

In addition, it seems that design-time  considerations may lend themselves
more to extensibility (vendor-specific  workflows), whereas the run-time
aspects seem to demand tight  interoperability.

And finally, there may be some  different technical requirements, for
example - performance seems to be a  key consideration for run-time but not
necessarily for design-time.

Thoughts, comments,  ideas?