OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

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


Subject: Re: [wsrp-interfaces] New Import Export document


Unless we come up with a use case for freezing the current state of the 
portlet, I presume that the copyPortlets would use the current state of 
the portlets.

Subbu

Tamari, Yossi wrote:

> But is the state still the same as it was when copyPortlets first 
> called? How do you do this?
> 
>         Yossi.
> 
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: Thursday, July 22, 2004 6:42 PM
> To: interfaces
> Subject: Re: [wsrp-interfaces] New Import Export document
> 
> I think copyPortlets() is replayable as long as the source registration
> is still valid and the source portlets are valid in that registration.
> 
> Subbu
> 
> Tamari, Yossi wrote:
>  > Hi Subbu,
>  >
>  > I think the use case document talks only about b. (quote: "the above
>  > scenario assumes that each consumer environment [development, stage,
>  > production] is talking to the same physical producer").
>  >
>  > However, the second use case is not supported by the copyPortlets
>  > operation, if I understand the operation correctly, since the import
>  > operation should be "replayable", so one export should create a
>  > "package" that can be imported many times at other consumers.
>  >
>  >         Yossi.
>  >
>  >
>  > -----Original Message-----
>  > From: Subbu Allamaraju [mailto:subbu@bea.com]
>  > Sent: Thursday, July 22, 2004 5:57 PM
>  > To: interfaces
>  > Subject: Re: [wsrp-interfaces] New Import Export document
>  >
>  > In the use cases document, I think we need to clearly distinguish
>  > between consumer-side migration issues from producer-side migration 
> issues.
>  >
>  > a. A Consumer customized some portlets of Producer. Producer is going
>  > from staging to production, while Consumer remains the same. There is a
>  > need to move portlet customizations across the Producers.
>  >
>  > b. The Consumer is moving from staging to production, while the Producer
>  > remains the same. In this case, the new Consumer wants to retain the
>  > same portlet customizations in a new registration context.
>  >
>  > If we are talking about (b), it is still not clear why a copyPortlets()
>  > like operation would not address it.
>  >
>  > Subbu
>  >
>  >
>  > Rich Thompson wrote:
>  >
>  >  >
>  >  > I agree that the burden of transferring portlets from one 
> registration
>  >  > to another belongs at the Producer. I'm not sure what about the
>  >  > export/import proposal changes that. If it relates to the use of a 
> POP
>  >  > handle on the import, I actually disagree that the Consumer should 
> need
>  >  > to do that dereference ... it ought to be the portletHandle
>  >  > corresponding to the exportedState.
>  >  >
>  >  > As to the use cases (see
>  >  >
>  > 
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/5614/Portlet%20Transport.htm) 
> 
>  >
>  >  > that seem to favor an approach that captures a snapshot of a 
> portlet's
>  >  > state:
>  >  > - Use case #1 refers to capturing a snapshot of a development system
>  >  > that is then pushed to the production system while development
>  >  > continues. I think it unreasonable to require the development 
> system to
>  >  > remain static for whatever duration is involved in deploying the
>  >  > snapshot on however many production systems it impacts.
>  >  > - Use case #2 makes snapshots even more important as the timing for
>  >  > deployment of the new Consumer in unknown. Certainly development 
> wants
>  >  > to continue on these systems as well.
>  >  >
>  >  > That said, import/export is not the only way to capture a snapshot.
>  >  > However, it is important that the solution we develop support the
>  >  > underlying use cases.
>  >  >
>  >  > Rich
>  >  >
>  >  >
>  >  > *Subbu Allamaraju <subbu@bea.com>*
>  >  >
>  >  > 07/22/2004 09:41 AM
>  >  >
>  >  >     
>  >  > To
>  >  >       Rich Thompson/Watson/IBM@IBMUS
>  >  > cc
>  >  >       interfaces <wsrp-interfaces@lists.oasis-open.org>
>  >  > Subject
>  >  >       Re: [wsrp-interfaces] New Import Export document
>  >  >
>  >  >
>  >  >     
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > I agree with Andre's suggestions, as it correctly puts the burden 
> on the
>  >  > producer to transfer portlets from one registration context another
>  >  > another without exposing any state.
>  >  >
>  >  >  > The main difference I see between such an operation and the 
> proposed
>  >  >  > export/import is that the operation references the current 
> state of a
>  >  >  > portlet while export/import proposal captures a snapshot and then
>  > looks
>  >  >  > to recreate it. For some of the use cases, I think this is an
>  > important
>  >  >  > difference.
>  >  >
>  >  > Could you elaborate this in the context of the use case? The use 
> case is
>  >  > about letting certain customized portlets be used from another 
> consumer.
>  >  > Import/export may be one particular way of solving it, but not the 
> only
>  >  > option, I think.
>  >  >
>  >  >  > I would suggest we not get involved in scenarios involving a
>  > migration
>  >  >  > of the Producer as well. How would a Consumer, in general, 
> learn the
>  >  >  > following scenario relative to Portlets exported from Producer1:
>  >  >  > - PortletA may be imported to Producer 2, but not Producer3
>  >  >  > - PortletB may be imported to Producer3, but not Producer2
>  >  >  > - None of the exported portlets may be imported to ProducerN
>  >  >
>  >  > Have we captured these with our use cases for this problem?
>  >  > Cross-producer import/export seems to be a new use case not 
> discussed so
>  >  > far.
>  >  >
>  >  >  > With the opaque nature of exportedState, Producers can easily 
> store
>  >  >  > enough information to allow automation of such cross-Producer 
> (same
>  >  >  > vendor implementation) imports. Out-of-band communication to the
>  >  >  > Consumer of which portlets a different Producer is able to import
>  > seems
>  >  >  > appropriate for our protocol (at least until other deployment
>  > protocols
>  >  >  > get defined that we could leverage).
>  >  >  >
>  >  >  > Rich
>  >  >  >
>  >  >  >
>  >  >  > *Andre Kramer <andre.kramer@eu.citrix.com>*
>  >  >  >
>  >  >  > 07/22/2004 06:45 AM
>  >  >  >
>  >  >  >                
>  >  >  > To
>  >  >  >                  "'Michael Freedman'" 
> <Michael.Freedman@oracle.com>,
>  >  > interfaces
>  >  >  > <wsrp-interfaces@lists.oasis-open.org>
>  >  >  > cc
>  >  >  >                
>  >  >  > Subject
>  >  >  >                  RE: [wsrp-interfaces] New Import Export document
>  >  >  >
>  >  >  >
>  >  >  >                
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  > As Exporting / Importing state has privacy and reliability issues,
>  > how
>  >  >  > far would the following operation go in covering the use cases?
>  >  >  >
>  >  >  > PortletHandle newHandle = copyPortlet(PortletHandle thePortlet,
>  >  >  > RegistrationHandle fromRegistration, RegistrationHandle
>  > toRegistration);
>  >  >  >
>  >  >  > This would normally be called by a wsrp consumer (e.g. when a 
> staged
>  >  >  > deployment goes live). I've purposely not included our
>  > portletState to
>  >  >  > show that no data need be passed outside of the producer(s). Two
>  >  >  > producers could pass portlet data between themselves (using a
>  >  >  > proprietary API or the proposed Export/Import mechanism) if the
>  >  >  > registrations are on different producers.
>  >  >  >
>  >  >  > Regards,
>  >  >  > Andre
>  >  >  >
>  >  >  >
>  >  >  >
>  > ------------------------------------------------------------------------
>  >  >  >
>  >  >  > *From:* Michael Freedman [mailto:Michael.Freedman@oracle.com] *
>  >  >  > Sent:* 22 July 2004 01:46*
>  >  >  > To:* interfaces*
>  >  >  > Subject:* [wsrp-interfaces] New Import Export document
>  >  >  >
>  >  >  > I have rewritten the original strawman to define specific
>  > import/export
>  >  >  > methods.  It has been _uploaded to the Interfaces documents_
>  >  >  >
>  >  >
>  > 
> <http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/7861/Import_Export2.html>. 
> 
>  >
>  >  >
>  >  >  >  If you want to refer to the old version click on "Manage" to 
> the far
>  >  >  > right of the document entry.  This takes you to a page where you
>  > can see
>  >  >  > the previous revision(s).
>  >  >  >     -Mike-
>  >  >
>  >  >
>  >
> 



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