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



I think there are the following alternatives
a: key customization data by portletInstanceID only and
b: key cusomization data by portletInstanceID and user/groupID

1 Creating the remote portlet instance inside the WSRP service

a. A portal calls a createPortletInstance operation to have a portlet
instance created, obtaining an instance handle as a result. If the remote
portlet service supports per-instance state, it returns a new handle for
each createPortletInstance call, otherwise it would always return the same
handle (as Yossi proposed).

It is up to the portal whether the instance created here in is used - it
may be attached to a public page shared by all users, to a group page
shared by a user group, to a personal page, or it may even be attached to
multiple pages. On the producer's side, the user independent instance would
be keyed in the service's database just by <portletInstanceID>.

To reference a remote portlet instance from a personal page, the portal can
attach the <portlet instance ID> to the personal page.
To reference remote portlet instances from a shared page assuring that the
users still can have their own customizations, the portal can attach a pair
of <user/group id, portletInstanceID> to the shared page to scope by user.

b. A portal passes a user/user group id with the createPortletInstance
operation to have a portlet instance created scoped to a user or user
group. If the remote portlet service supports per-instance state, it
returns a new handle for each createPortletInstance call, otherwise it
would always return the same handle (as Yossi proposed).

It is up to the portal whether the instance created here is used - it may
be attached to a public page shared by all users, to a group page shared by
a user group, to a personal page, or it may even be attached to multiple
pages. The instance would be keyed in the service's database by
<portletInstanceID, user/userGroup>

To reference a remote portlet instance from a personal page, the portal can
attach <portlet instance ID> to the personal page.
To reference remote portlet instances from a shared page assuring that the
users still can have shared customizations, the portal can attach the
tuples of <group id, portletInstanceID> to the shared page.

2 Usage of remote portlet instances

a. A portal invokes the processAction / getMarkup operation passing the
portlet instance ID and optionally the current user id. While the user id
and profile information that comes with it may be used for personalization
of the output, the target instance and therefore the customization is
solely identified based on the portlet instance ID.

b. A portal invokes the processAction / getMarkup operation passing the
portlet instance ID and mandatorily the current user id. The user id and
profile information that comes with it may be used for personalization of
the output. The target instance and therefore the customization is
identified based on the portlet instance ID and the user ID.

3 Deletion of remote instances

a. A portal calls the deletePortletInstance operation passing just the
portletInstanceID

The portal knows all instances tied to a page and may delete them all.

b. A portal calls the deletePortletInstance operation passing the
portletInstanceID and user/groupID

The portal does not know all instances tied to a page since it doesn't know
for which users that have access to a page the portlet on the page was
customized -> it cannot easily delete all per-user instances.

Tradeoffs:

Option a seems simpler for the WSRP producer, it just needs to operate on
instance ids and may ignore user ids. It may use user ids for
personalization, but doesn't need to take them into account for
customization and persistent state. At the same time, option a gives more
control to consumers, since the consumer controls the mapping of
<user/group id, local portlet ID> to <portletInstanceID>. It requires pairs
of <user/group id, portletInstanceId> to be attached to shared pages for
embedding remote portlets while allowing per user customization. This
information allows complete deletion of all user-customized instances
attached to a page.

Option b seems more complex for WSRP producers, and does take away
flexibility implied by the control of the mapping from <user/group id,
local portlet ID> to <portletInstanceID> from the consumer. It only
requires <portletInstanceID> to be attached to shared pages embedding
remote portlets, since the current user ID woud be passed to the producer
for per-user customization. Not having an explicit association of all
customized portlet instances with the page however means that the portal
cannot delete all of them if required.

Option a seems preferrable to me, since it makes thinks easy for the
producer (of which there will be a large number) and is flexible since it
leaves the mapping to customizable instances to portal server products
rather than doing it at the producer side. Also, Option b seems to lead
into problems with cleanup when all customized instances assiciated with a
shared page need to be deleted.

Best regards,

Thomas

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


"Cassidy, Mark" <mcassidy@Netegrity.com> on 05/10/2002 05:59:52 PM

Please respond to "Cassidy, Mark" <mcassidy@Netegrity.com>

To:    "'Tamari, Yossi'" <yossi.tamari@sapportals.com>, "'Michael Freedman
       '" <Michael.Freedman@oracle.com>, "'WSRP '"
       <wsrp@lists.oasis-open.org>
cc:
Subject:    RE: [wsrp][interfaces] Portlet instance handles



>  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?

As long as the per-instance personalization is provided for, whether it's
done via the personalization being tied to the instance handle or through a
level of indirection given some sort of userID that's transferred along
with
the instance handle, the same end result is accomplished.  The key point is
that per-instance personalization is required.  From a security
perspective,
I agree with Yossi:  there are many content scenarios where user's
'personalize' their view(of a portlet instance) without needing to provide
any identifying information about themselves.

Seems that any bloat associated with having handles being
per-user/per-instance would be proportional to the number of portlet
parameters that are shared across users of an instance versus the number of
parameters that are personalizable by each user.  From my experience, the
persistent data managed for individual user personalization is the largest
component. Bloat may not be as big an issue given that we have to support
per-instance personalizaton in some fashion.


-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com]
Sent: Friday, May 10, 2002 6:31 AM
To: 'Michael Freedman '; 'WSRP '
Subject: RE: [wsrp][interfaces] Portlet instance handles


Hi Mike,

The way I was looking at the handle was as an opaque generated by the
portlet and returned to it on consecutive calls by the portal.
The portal will probably have its internal handle for each portlet, but
this
is outside our scope.
The idea here is that the portlet CAN generate a different handle for every
user, if it manages personalization data, or it can return the same handle
for all users.
The advantage of this over passing the user id is that the portlet know
that
this is the same user that requested it before, but it doesn't know WHO
this
user actually is. This gives the user an added layer of privacy (for
portlets that do not require profile or user information).

          Yossi.

-----Original Message-----
From: Michael Freedman
To: WSRP
Sent: 5/9/02 11:47 PM
Subject: [wsrp][interfaces] Portlet instance handles

Folks,
   In a number of subcommittees I believe it has been expressed/assumed
that:
        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?
   -Mike-




----------------------------------------------------------------
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