I was assuming the consumer must do the
clone explicitly and, by our normal protocol, must clean up. So no dangling clones
(especially if its lifetime is managed by a leasing contract). A producer can
still "push" state to the consumer via the normal PortletContext.portletState
(which I did not include in the signature in order to focus on the by-reference
case).
Regards,
Andre
From: Rich Thompson
[mailto:]
Sent: 22 July 2004 19:17
To: interfaces
Subject: RE: [wsrp-interfaces] New
Import Export document
Yes, but this leaves a dangling clone that the Producer
will never know whether or not to clean up. Much the same as if export returned
a reference to a snapshot of a portlet's state. Export has the advantage that a
Producer could choose to push that snapshot to the Consumer and not have
to worry about cleaning up the storage.
Rich
Andre Kramer
<>
07/22/2004 01:05 PM
To
interfaces
<>
cc
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:]
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:]
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-
> >
> >
>
