Re: [wsrp] WSRP 2.0 issue: Need to foramlize receiving/respondingclient meta data on in-protocol getResource

[Subbu Allamaraju <subbu@bea.com>]

Sorry, but I can't help point out these threads from the archives.

http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200504/maillist.html#00084

http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200607/msg00000.html

I know you are coming from a specific use case, but the general problem 
has been good enough for me. We dropped the ball twice on this topic 
already.

Subbu

Michael Freedman wrote:
> Though the WSRP 1.0 specification is mute on the subject (I believe) the 
> expected behavior of consumer based proxied http resources is that 
> client request meta data is propogated to the resource via http request 
> headers and client response meta data is propogated back via http 
> response headers.  I.e. the consumer acts as an http proxy by and large 
> passing thorugh the client request headers and returns in the client 
> response headers those it received in the resource response.
> 
> In WSRP 2.0 we added in protocol resource serving.  As the structure of 
> this call is based on the information passed in a regular GetMarkup 
> passing client request and response meta data is more muddled.  The 
> MimeRequest structure contains fields that correspond to the content 
> type, character set and locale of the resource request.  Though unstated 
> these are expected to come from the corresponding client request 
> headers.  In addition the clientData field passed in MimeRequest 
> contains the userAgent, request verb, and ccppHeaders.  Again the 
> expectation is these come from the client request headers.  In 
> MimeResponse there are corresponding fields to carry the content type 
> and locale of the response, caching information and ccpp profile 
> warnings.  Again the expectation is that the consumer ultimately encodes 
> these properly into the client response headers.
> 
> In WSRP 2.0 we have said (encouraged) Ajax developers to use our 
> in-protocol getResource to convey the ajax request.  We have been 
> hearing from some Ajax developers (JSF AJax impelmentations) that they 
> rely on encoding information about the partial rendering in the client 
> request headers.  To work these implementations need to be assured that 
> such headers are passed to the producer in a consistent, interoperable 
> way.  Though at the moment these developers haven't indicated a 
> reciprical reliance on the http response headers, its not hard to 
> imagine systems utlizing this mechanism to convey reponse meta data back 
> to itself so its client javascript can properly handle the response.
> 
> To support this WSRP 2.0 needs to have a formal definition of how client 
> request meta data not already represented in specific fields in the 
> ResourceParams , MimeRequest, or ClientData structures are passed and 
> likewise how client response meta data not already represented in 
> specific fields in ResourceResponse, ResourceContext, or MimeResponse 
> are returned.
> 
> The solution is to define that both these extra request/response meta 
> data is carried in a NamedStringArray.  With the semantic in an http 
> client environment that there is one name/value per http header with the 
> name being the header name and the value being the header value 
> exlcuding those headers that are either overriden by the consumer or 
> reflected directly in the passed request data.  Likewise there is one 
> name/value pair for each additional piece of response meta data (other 
> then what is already reflected in the response data) where the name 
> becomes the http client response name and the value is value.
> 
> The primary question/issue is where to represent this NamedString 
> array(s).  There are a variety of options for requests all of which rely 
> on using a NamedStringArray:
> 
>     * Define a standard extension to be carried in the extension field
>       of the ClientData structure and require its use for getResource()
>     * Add an additional field in the ClientData called XXX
>       (otherClientAttributes???) and require its use for getResource()
>       (and other operations?)
>     * Define an additional field to ResourceParams called
>       resourceAttributes???
> 
> Likewise there are a variety of options for responses all of which rely 
> on using a NamedStringArray:
> 
>     * Define a standard extension to be carried in the extension field
>       of the MimeResponse structure and require its use for getResource()
>     * Add an additional field in the MimeResponse called XXXX
>       (clientAttributes?) and require its use for getResource() (and
>       other operations?)
>     * Define an additional field in ResourceResponse called
>       resourceAttributes???
>     * Define a standard extension to be carried in the extensiuon field
>       of the ResourceResponse.
> 
> -Mike-
> 
> 
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.