OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp][interfaces] Portlet instance handles

IMHO, the relationship or binding between the consumer and producer should
be through the single handle which is established at registration time
between the consumer and producer.  that handle if it is determine that the
producer maintaines statefull information should be associated by the
consumer with the currently running user/page/portlet instance.  I
potentially am not following the thread, but the inclusion of another key
seems to increase the complexity from both sides, but I am more than willing
to hear others blast my confusion.


-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, May 10, 2002 9:10 AM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces] Portlet instance handles

In addition to Alan's comments, I would note that the handle we have been
discussing is an opaque remote reference to a runtime entity capturing the
(transient) state of the interaction of a particular "session" with a
particular Consumer. How a Consumer maps these to End-Users is an
orthogonal issue, though establishing a one-to-one coorespondance is the
most straight forward solution. More recent discussions are beginning to
think about how these might map into a set of persistent data the Producer
has stored for the Consumer to reference when initiating "sessions". I
would like these to use a different name (suggestion = key) in order to
reduce confusion when discussing the difference with handles in both
syntactic and semantic use. Mike, using these words, your suggestion maps
into there being a key (has persistent data about the relationship between
the portal and portlet) the portal uses in combination with data from a
user profile when establishing a session for an End-User. The portlet would
produce/return a handle used to reference that session's state.

                      Alan Kropp
                      <akropp@epicentri        To:       "'Michael
Freedman'" <Michael.Freedman@oracle.com>,
                      c.com>                    WSRP
                      05/09/2002 06:02         Subject:  RE:
[wsrp][interfaces] Portlet instance handles

Agree with Mike here..from the WSIA side, we've been talking about the
handle as a reference constructed expressly for, and for the exclusive use
of a given Consumer.  To the extent that the service (portlet provider)
needs visibility as to 'who' the End User really is, this should be
information that's passed along with the request the Consumer constructs on
behalf of the End User, within the bounds of the trust relationship in
effect between Consumer and Producer.


-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Thursday, May 09, 2002 2:47 PM
Subject: [wsrp][interfaces] Portlet instance handles

   In a number of subcommittees I believe it has been expressed/assumed
        a) Portlet instances have unique persistent ids/handles that
will be retained both by the portal and the portlet service.
        b) A portlet instance (handle) corresponds to a given user of a
given portlet on a portal page.
        c) This handle will be generated by the portlet service.

   I have been surprised by (b) being part of the assumption and would
like to understand better why folks feel this the right way to model
things.  I am surprised because it seems to require the portal maintain
N instance references per portlet on a page where N corresponds to the
number of users (who have visited this page).  Representing a database
company I guess I should be happy that we want this data bloat ;-)
Seriously, however, I would like to understand why we think its
proper/necessary to manage this persistent id when a more lightweight
mechanism exists -- namely one persistent id that represents the portlet
instance on the page + the current user identity.  Basically, it seems
the downside of the assumed/proposed approach are large(r) data sets
being maintained in the portal that likely makes export operations,
upgrades, etc. more expensive.  In addition it requires the portal to
runtime map from an obvious key (the page's portlet instance and the
user id) to this handle.
   On the surface it seems that portlets need an id that represents a
portal's portlet page instance on a per user basis as a key to that
user's personalization data for that portlet instance.  Are there other
needs for this key?  If not why do we need to generate such an id if
there is no personalization data or if the personalization is being
managed by the portlet itself (in this case the portlet can choose to
generate its own id and managed the mapping itself)?  And even if the
portal is maintaining the personalization data why can't it choose the
key itself?

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC