The problem you seem to be ignoring is the
second use case, of exporting once and importing multiple times. The way to
solve this with copyPortlets is:
The exporting consumer clones the portlet on
export, and then the importing consumer clones again on import. But then we
have the “dangling” copy, which we can’t delete, since it may
be imported again, and the leak is the same as in Mike’s proposal if
exportData is used to store the handle.
The point I am trying to make is that Mike’s
proposal is an extension of copyPortlets, with no extra cost, but with more flexibility.
Yossi.
From: Andre
Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Thursday, July 22, 2004 8:05
PM
To: interfaces
Subject: RE: [wsrp-interfaces] New
Import Export document
A clone of the portlets to "freeze" them
perhaps? (either within a registration or to a new registration).
Regards,
Andre
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: 22 July 2004 17:02
To: interfaces
Subject: RE: [wsrp-interfaces] New
Import Export document
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-
> >
> >
>