Re: [wsrp-interfaces] Groups - Import_Export.html uploaded

[Rich Thompson <richt2@us.ibm.com>]

Mike,

In reading through this proposal, the
following questions arose:

1. Under "Basic Goals" you
talk about the Consumer receiving the portlet state needed to create a
new portlet with equivalent state from a different Consumer. My first impression
is that it is too early to declare the needed information to just be the
portlet state the protocol currently defines and confusing if this reference
is meant to be broader.

2. Accordingly to the comments in #1,
the assumption (in "Acquiring Portlet State") that the Consumer
has all the information it needs to fully package and redeploy itself when
it has access to the optional portletState field is a stretch. Even when
the Producer sends this optional field, it is not required to be the full
portlet state nor guaranteed to be all the information needed to create
an equivalent clone.

3. I understand the comments you make
about desiring to extend the current API, but am concerned that this effort
will result in situations where the semantics are difficult to use to accomplish
the means. As a result, the first question I would ask is whether the new
portlet factory sequence (conceptually export/package/deploy/import) needs
to build off the current factory sequence (publish/find/bind/clone). If
there is no need to conceptually align these factory mechanisms, then I
would not align them unless we are certain that the alignment will make
it easy for implementations to implement the multiple factory mechanisms
without loss of intended function. I am not convinced (though am open)
that this will be true. Asa result, I would prefer exploring what this
would look like if it were an export operation that returned an array containing
the requestedPortletHandle and exportedPortletState (an opaque representation
of whatever the Producer will need to recreate the portlet) and an import
operation that accepted such an array and returned an array with requestedPortletHandle
and newPortletContext. This would allow us to explore the semantics without
being stressed about what impact it would have on current APIs and then
explore at the end whether any of the resulting definitions can reasonably
be collapsed into the current APIs.

Rich

Michael.Freedman@oracle.com

07/01/2004 12:25 PM

To	wsrp-interfaces@lists.oasis-open.org
cc
Subject	[wsrp-interfaces] Groups - Import_Export.html uploaded

The document Import_Export.html has been submitted
by Michael Freedman (Michael.Freedman@oracle.com) to the WSRP Interfaces
SC document repository.

Document Description:


Download Document:  
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/7534/Import_Export.html

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=7534


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy
and paste
the entire link address into the address field of your web browser.