[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] New Import Export document
Yes, as I said the only value I see is the snapshot.
And it is definitly valueable.
However we didn't stress this in the initial use case, therfor other
solutions seemed to fit better here.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
"Tamari, Yossi"
<yossi.tamari@sap
.com> To
interfaces
07/22/2004 04:41 <wsrp-interfaces@lists.oasis-open.o
PM rg>
cc
Subject
RE: [wsrp-interfaces] New Import
Export document
Hi,
I would like to stress that there is nothing in Mike's proposal that
requires the producer to put any actual data in the exportData field. It
can store a cloned protletHandle there if it chooses. This proposal simply
gives the producer more freedom as to how it wants to implement the export
operation. It can clone, it can encrypt all the properties, and it can just
put them in free text, just like with consumer managed persistence.
I think the use case of "export once import many" is important since it
allows one "person" to build content packages for multiple clients, which
is some companies' livelihood.
Yossi.
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: Thursday, July 22, 2004 5:13 PM
To: interfaces
Subject: Re: [wsrp-interfaces] New Import Export document
I tend to agree with Andre and Subbu,
I think we need to distinguish the use cases here.
The initial use case was to allow "staging to production" of the consumer
and we should keep this in mind.
For this use case I wonder why a copyPortlet[s](Portlets[],
fromRegistration, toRegistration) is not enaugh?
It would not add any protocol/network overhead, would lower or even
eliminate privacy/security issues, we wouldn't need special metadata like
hierarchie information, etc.
What is the reasoning for going through the Consumer?
The only advantage I see the snapshot of the configurations.
The second use that seems to creep in is the porting of producer setups.
Here we would deal with many other issues like versioning etc. i.e. we
would need metadata to specify various type information.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Subbu Allamaraju
<subbu@bea.com>
To
07/22/2004 03:41 Rich Thompson <richt2@us.ibm.com>
PM cc
interfaces
<wsrp-interfaces@lists.oasis-open.o
rg>
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]