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:]
> 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:]
> > 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 <>*
> > >
> > > 07/22/2004 09:41 AM
> > >
> > >
> > > To
> > > Rich Thompson/Watson/IBM@IBMUS
> > > cc
> > > interfaces <>
> > > 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 <>*
> > > >
> > > > 07/22/2004 06:45 AM
> > > >
> > > >
> > > > To
> > > > "'Michael Freedman'"
> <>,
> > > interfaces
> > > > <>
> > > > 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:] *
> > > > 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-
> > >
> > >
> >
>
