Re: [wsrp] Rationale for encouraging POP handles be UIDs

[Subbu Allamaraju <subbu@bea.com>]

Since the Producer chose to return different portletHandles for POPs, as 
far as the Consumer is concerned, there are two different sets of portlets.

If you are talking about different *versions* of the same portlet, 
unfortunately we don't have any semantics to denote versioning, and 
compatibility guidelines. But it way be worthwhile to pursue that.

But without such facilities, I'm not sure if the Consumer can safely 
assume that the new set of portlets are the same as the old set of 
portlets. That may be a risky thing to do.

Subbu

Michael Freedman wrote:
> Resending to whole list with edited first sentence [so its actually a
> sentence]
> 
> Yes,  that is one manifestation of the scenario.  The type of situation
> this may commonly occur in is when the two installations of the Producer
> are different versions [of the same producer].  If one version has
> removed a portlet from a prior version its conceivable/allowable for the
> removed POP handle to be resused.
> 
> Basically, I am asking us to codify the rules for how a consumer
> establishes the relationship between the POPs in these two registrations.
>      -Mike-
> 
> Michael Freedman wrote:
> 
>  > As that is one manifestation of the scenario.  The type of situation
>  > this may commonly occur in is when the two installations of the
>  > Producer are different versions [of the same producer].  If one
>  > version has removed a portlet from a prior version its
>  > conceivable/allowable for the removed POP handle to be resused. 
>  > Basically, I am asking us to codify the rules for how a consumer
>  > establishes the relationship between the POPs in these two 
> registrations.
>  >      -Mike-
>  >
>  > Subbu Allamaraju wrote:
>  >
>  >> Mike,
>  >>
>  >> If I understand your use case correctly, the Producer is offering a
>  >> new set of POP handles in its service description upon new
>  >> registration. I'm not sure why the Producer would want to assign a
>  >> new set of portlet handles for each registration for the *same* set
>  >> of portlets. But I agree that it is free to do so.
>  >>
>  >> Let's say, originally, the Producer offered portletA.
>  >>
>  >> The Consumer stored the metadata of the portlet some place, and
>  >> possibly also created CCPs.
>  >>
>  >> When the deployed Consumer tries to establish the registration, let's
>  >> say, the Producer offers portletA1 and portletB1.
>  >>
>  >> The problem is, how should Consumer guess that portletA1 and portletA
>  >> are the same, and some new portletB1 is not the same as portletA?
>  >>
>  >> Is this the use case?
>  >>
>  >> Subbu
>  >>
>  >> Michael Freedman wrote:
>  >>
>  >>>
>  >>> So why the need for unique POP handles?  The answer lies in that its
>  >>> reasonable to expect such consumer applications to manage [its cache
>  >>> of]
>  >>> portlet meta data in an efficient manner by relying on a single record
>  >>> for all the portlets derived from a common POP.  In such an
>  >>> implementation, the consumer needs a mechanism for rewiring these
>  >>> references when a producer connection is retargeted.  I.e. at
>  >>> deployment
>  >>> a new registration happens resulting in a new set of POPs and
>  >>> associated
>  >>> portlet meta data being read into the application cache.  The
>  >>> application now wants to ensure that all its portlets from that
>  >>> producer
>  >>> are properly rewired to point to this new meta data. Somewhere along
>  >>> the
>  >>> line the consumer is going to need to figure out how POPs in the
>  >>> packaged application relate to the POPs in the actual deployment. 
> [i.e.
>  >>> either from the POP point of view to figure out which meta data record
>  >>> this portlet description shoudl overwrite or from the cloned portlet
>  >>> point of view if the cloned portlet indirectly references its
>  >>> description via a POP reference/key].  Being able to rely on the 
> strong
>  >>> suggestion/requirement that POeP handles are unique minimizes th guess
>  >>> work involved.  I.e. trying to implement a heuristic that matches meta
>  >>> data values to identify the relationship.
>  >>>    -Mike-
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> ---------------------------------------------------------------------
>  >>> To unsubscribe from this mail list, you must leave the OASIS TC that
>  >>> generates this mail.  You may a link to this group and all your TCs
>  >>> in OASIS
>  >>> at:
>  >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >>>
>  >>
>  >>
>  >> ---------------------------------------------------------------------
>  >> To unsubscribe from this mail list, you must leave the OASIS TC that
>  >> generates this mail.  You may a link to this group and all your TCs
>  >> in OASIS
>  >> at:
>  >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
>  >
>  >
>  >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>