There are real-world scenarios where
this happens, but trying to manage it within the WSRP protocol doesn't
seem reasonable to me. On the other hand, it keeps coming up in the discussions
on import/export. I think we need to explicitly decide to exclude it from
consideration.
Rich
Subbu Allamaraju <>
07/22/2004 09:53 AM
To
Rich Thompson/Watson/IBM@IBMUS
cc
interfaces <>
Subject
Re: [wsrp-interfaces] New
Import Export document
Rich,
You mention cross-producer import/export below. I wonder if such
import/export is practical since there is no way for the consumer to
know that the second producer offers the same (code + data) portlet
(even if the exporting producer was able to encapsulate such information
in the binary state).
Subbu
Rich Thompson wrote:
>
> 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.
>
> 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
>
> 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-
