[wsrp][interfaces]: Agenda for June 6th conference call

IMPORTANT:  Conference call starts at 7:30am PDT (10:30 EDT, 4:30
CET?).

Number and conference id is still the same: 877-302-8255 or 303-928-2609

ID: 8814427

This time change is for this week only.

Agenda:

1) Alert new mailing list for this subcommittee. Subscribe now! ()
Starting next Monday all e-mails targeting [interfaces and protocols] should
go to this list.

2) Continue discussing requirements.  We are going to skip ahead
a little and discuss the session requirements (described at end of this
message) as we are still waiting for other requirements to be written up.

3) If time we will discuss Alejandro's "Separate Administration Interface"
issue.  (See mail discussion from this past week.

 

(Draft) Session requirements:

Sessions:
This section discusses the requirements for creating/managing and deleting
sessions in support of transient information.
 

R22: [must] The specification must allow a portlet service to
maintain transient information on an N to 1 basis where N is the number
of discrete representations of transient data per portal and 1 being the
portlet service.

Q6:  Do we need to support maintaining
transient data at the entity/instance level as well or is the session sufficient? 
If we do need to maintain per instance transient data is this scoped to
the session or not?  I.e. is there a transient ID per portlet instance
per session or just one transient ID per portlet instance across all sessions
(of a single portal).

R23: [must] The specification will provide this support by defining
the concept of a session.  A session will be an identifier passed
between the portal and the service that allows the portlet entity to map
back to the discrete transient information.

R24: [must] The specification must allow the portal to define
the [portal] scope of the session.  I.e. though its likely that a
session is mapped to a user the portal must be free to define alternative
scopes.

R25: [must] A session must be able to span all portlets managed
by the portlet service.

R26: [must] The specification must allow for the session to be
created either at the instigation of the portlet or the instigation of
the portal.

Q7:  This begs the question of how? 
I.e. how should we deal with the complexities of creating sessions in a
concurrent world?  For example:  if we allow portlets to create
sessions at any time by returning an id don't we imply the requirement
that the service manage the race condition?  I.e.  where two
portlets that should run in the same session receive a concurrent request
from a portal where no current session ID exists, doesn't the service need
to guarantee that each portlet receives the same newly created session
if both ask for one?  If so how does the service know which portlets
(requests) belong to the same session?  Another worrisome case occurs
again when portlet A and B receive concurrent requests with no current
session ID indicated.  In this case A requests a session but be does
not.  I.e. A returns a session id but B doesn't.  What must the
portal do in this case?  Do we require the portal to recognize the
return from A and send it to B on all subsequent requests.  The final
case occurs when sessions go style -- portlet A and B are running in the
same session signified by ID XXX.  Portlet B receives a request, recognizes
the session has timed out and creates a new session/returns a new ID. 
What must the portal do in this case?  Must it recognize the change
and pass the new sessionID to A on subsequent requests?  The alternative
to this mess is to define the API where the portal must create the session
explicitly via a createSession call.  In this way it can make the
call prior to sending any concurrent requests.  To handle the session
timeout situation we would define that portlet methods could return a SessionInvalid
error -- the portal would be required to create a new session and retry
the operation that failed.

R27: [must] A portal must maintain sessions needed by the portlet
service.

R28: [may] A portlet service may choose to not create a session
when requested to do so by the portal.

R29: [must] However if it chooses to not create upon request,
it must never create a session as a side effect in future request processing. 
A portal may ignore such sessions created by non conforming services.

R30: [must] The specification must allow a portal to tell the
portlet service when a session is not longer valid/active.

R31: [may] A portal need not tell the portlet service when a
session becomes invalid/inactive.

R32: [may] A portlet service may invalidate/inactivate a session
at any time.  A portlet service need not tell the portal when such
invalidation/inactivation occurs.

R33: [must] A portal must never send a known invalid/inactive
session to a portlet service.

R34: [must] A portlet service must be able to describe whether
or not any of its portlets require session maintenance.

Q4: [open]  Do we want/need to describe
which portlets need sessions -- or sufficient as a boolean?