Re: [wsrp-interfaces] New Import Export document

[Subbu Allamaraju <subbu@bea.com>]

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