[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] New Import Export document
This is partly why I suggested cloning over registrations. These can control who can modify the copied portlets (i.e. she who knows the registration handle). Alternatively, its just conventions on cloning (for "export" or "freeze") or for "import" / "copy" that seem to be needed, unless we have real needs to export portlet state/data.
Regards,
Andre
-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 26 July 2004 17:27
To: interfaces
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]