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] | [List Home]


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


Rich Thompson wrote:
> 
> It would be good to reunify the two branches of this email thread ....
> 
> I can see the value of having a means by which a Consumer can tell what 
> would be the equivalent Portlet when it begins using a different 
> Producer. The problem is that the Consumer only has the 
> PortletDescription (i.e. metadata) to attempt such a determination and 
> all of the metadata fields are subject to change by the Producer. 
> Recommending the portletHandle be a UID or even GUID might help for 
> crossing registration boundaries within a Producer (normally the 
> portletHandle will be invariant anyway, so this would be a marginal 
> improvement), but would not likely help when switching Producers. To

I agree. Across producers, UIDs won't help.

Subbu

> truly assist the Consumer, invariant information from the packaging of 
> the Portlet would be required and it would help if this separately 
> identified the Portlet's version. We could define such fields in the 
> metadata, but where would the data come from?
> 
> Rich
> 
> 
> *Michael Freedman <michael.freedman@oracle.com>*
> 
> 04/06/05 05:31 PM
> 
> 	
> To
> 	wsrp <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	Re: [wsrp] Rationale for encouraging POP handles be UIDs
> 
> 
> 	
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 



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