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

[Michael Freedman <michael.freedman@oracle.com>]

I don't think its strictly/technically true that the Consumer see two 
different portlets.  The point of the issue I raised [as Rich has 
clarified] is that mapping between two installations of a producer is 
not defined.  Technically speaking the consumer can only approximate 
equivalence by comparing values in the meta data including the POP 
handle.  I am suggesting we move towards a more definitive method.
    -Mike-

Subbu Allamaraju wrote:

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