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

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

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