OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrp-interfaces] New Import Export document


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:richt2@us.ibm.com]
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 <andre.kramer@eu.citrix.com>

07/22/2004 01:05 PM

To

interfaces <wsrp-interfaces@lists.oasis-open.org>

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

>  >

>  >

>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]