Re: [wsrp] exportData field in ExportedPortlet Structure

Current text says "The
exported data which is required to create a copy of the Portlet using the
importPortlets operation".
This gives the Producer complete freedom to put whatever in the field,
provided it can create a copy of the portlet using that information. This
easily covers both the byReference and byValue export styles. What text
are you thinking would be clearer for all cases?

Rich 

Subbu Allamaraju <>

05/27/05 02:15 PM

To

wsrp <>

cc

Subject

Re: [wsrp] exportData field
in ExportedPortlet Structure

I would like to suggest that we add some wording around
"exportData" to 

clarify what this might contain, and why this is not directly related to

exportByValue.

Subbu

Rich Thompson wrote:

> 

> I think you misunderstood my comment. Here is the sequence as I understand:

> 

> 1. Consumer uses a portletHandle to request the export of a portlet

> [Note: actually uses the portletContext to handle case where state
is 

> stored at the Consumer].

> 2. Producer returns the portletHandle (reference to the request) and

> exportData (what is required to import the portlet)

> 3. Consumer invokes import passing an importID and the exportData
[Note 

> that there is no reference to the original portletHandle!]

> 4. Importing Producer returns the importID (reference to the request)

> and a new portletHandle (within a portletContext)

> 

> I don't see how exportData could be optional ... I do see how a Producer

> might just copy the portletHandle as exportData.

> 

> Rich

> 

> 

> *Subbu Allamaraju <>*

> 

> 05/27/05 11:00 AM

> 

>                  

> To

>                  wsrp
<>

> cc

>                  

> Subject

>                  Re:
[wsrp] exportData field in ExportedPortlet Structure

> 

> 

>                  

> 

> 

> 

> 

> 

> Yes, but if the Producer decides not to supply exportData, the Consumer

> won't be required to send it with importPortlets message. So, I don't

> see making exportData optional changing any semantics.

> 

> Consider the case where the producer is able to export all portlets
by

> reference. Then the producer could return a message like

> 

> <exportPortletsResponse/>

> 

> But if the producer is able to export only a few portlets, it will
have

> to return a response like

> 

> <exportPortletsResponse>

>   <exportedPortlets>

>     <portletHandle>foo1</portletHandle>

>     <exportData>xxxxx</portletHandle>

>   </exportedPortlets>

>   ...

> </exportPortletsResponse>

> 

> So, the producer is forced to make up some exportData element. This

> seems awkward.

> 

> Regards,

> 

> Subbu

> 

> Rich Thompson wrote:

>  >

>  > It is the exportData field that will get supplied to the
import

>  > operation. The portletHandle field is there just as a reference
since

>  > export is a bulk operation. It certainly would be valid
for a Producer

>  > to merely place a copy of the portletHandle in the exportData
field.

>  >

>  > Rich

>  >

>  >

>  > *Subbu Allamaraju <>*

>  >

>  > 05/26/05 06:25 PM

>  >

>  >                
 

>  > To

>  >                
 wsrp <>

>  > cc

>  >                
 

>  > Subject

>  >                
 [wsrp] exportData field in ExportedPortlet Structure

>  >

>  >

>  >                
 

>  >

>  >

>  >

>  >

>  >

>  > I might have asked this before, but could someone clarify
why exportData

>  > field is required in ExportedPortlet structure.

>  >

>  > If the producer does not support export by value, and the
consumer sends

>  > an exportPortlet request with exportByValue=false, the
Producer should

>  > be allowed to return the handles of exported portlets without

>  > exportData. Any reasons for making this a required field?

>  >

>  > Subbu

>  >

>  > ---------------------------------------------------------------------

>  > To unsubscribe from this mail list, you must leave the
OASIS TC that

>  > generates this mail.  You may a link to this group
and all your TCs 

> in OASIS

>  > at:

>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

>  >

>  >

> 

> 

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  You may a link to this group and all your
TCs in OASIS

> at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> 

> 

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your TCs
in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php