Hi Rich,
Thanks to pointing us all to the use case
documents. I see two important points in it relevant to recent emails:
- The
second use case requires the “export once import many” feature
I mentioned before.
- The
first use case (end of its second paragraph) requires the distinction
between edit and config properties that we discussed in the “hierarchy”
thread.
And congratulations for all of us for
finally waking up from the post-1.0 slumber ;->
Yossi.
From: Rich
Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, July 22, 2004 5:37
PM
To: interfaces
Subject: Re: [wsrp-interfaces] New
Import Export document
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-