OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] Groups - CCPP-support-draft03.html uploaded




Hi Richard,

I tried to collect some data on how CC/PP is used and the role it is expected to play from the product team here. So based on that input and the following open issues we currently have on the table, some comments inline below.

<issue 1>
     Is ClientData only intended for markup generation only? Or should it also apply to performBlockingInteraction (use cases seem to exist)? In that case shouldn’t we move the ClientData structure to the RuntimeContext? Note: MarkupParams are available in pbia, too so principally ClientData is accessible in that phase.

We want to support use cases to have the profile information available in other operations, too. Especially in pbia() and handleEvents().
Decision was taken to move just the CCPPHeaders structure to RuntimeContext and leave ClientData as is for backward compatibility reasons.
</issue 1>

I'm told that the CC/PP information sent by the user agent (client/device) may be used by the "origin server" for any purpose. For example, the server could use it to modify markup, or use it to paginate intelligently for a given display size, or transcode images transparently or whatever.

<issue 2>
2.     If 1. applies also to pbia, should pbia be able to return the CCPPProfileWarning, too? And if yes, what would the Consumer do with it?
Currently it seems only to be valueable to return with markup.

Decision was taken to just return it with markup to the client for now. Atul to come up with further use cases which would require to return the warning header in other operations, too and thus allow the Consumer to handle them.

</issue 2>

I've been referred to section 6 of the CC/PP exchange protocol based on HTTP Extention Framework which illustrates examples of how the CC/PP headers and return warnings may be used by the origin server as well as  by "hops". These "hops" are intermediaries (typically proxies). Our Consumer and Producer tiers would also qualify as hops and hence may utilize the CC/PP headers as shown in sections 6.3 and 6.4 of the document. So essentially, any Producer or Consumer that could use CC/PP headers to optimize its behavior for a particular device should be able to do so.

I'm also told that how the device processes the CCPPProfileWarning headers would be device specific. In some cases it may be best to pass it on, so that future, more intelligent servers and devices can make use of it. Section 5.2.3 of the exchange protocol document states "The server SHOULD respond to the client with the Profile-warning header field if any one of the CC/PP descriptions could not be obtained, or any one of the CC/PP descriptions is stale". Hence in the interest of being fully CC/PP capable,  it may make sense to have the ability to pass this back via the protocol.

Beyond passing CC/PP information back and forth, one other issue we have not discussed is - currently the portlet meta data in WSRP is sliced by mime types only, i.e. you only get back modes, window states, locales, etc supported per MIME type. I'm told that while optimizing content for a device, there are several parameters to consider. A short list would be: Accept header mime types, screen size and resolution, number of colors supported, does it support java applets etc. Currently we only support the first one (accept mime types). This may not be sufficient for optimizing content since the Producer would only invoke the portlets that can adapt content for the requesting device. MIME type is insufficient because information that is important in determining whether a portlet can support a particular device, such as screen size and color support, cannot be inferred based on the MIME type. I'm told that CC/PP UAprof may be of help.  I have not had a chance to reivew yet, but we should look at this in detail.

Thanks

Atul


Richard Jacob wrote:


Hi guys,

I wanted to be a good boy and modified the document before being out next
week. I added the changes we discussed to the next rev.
I haven't added any examples for now. (sorry Subbu ;-) )
Happy reading.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Standardization Technical Lead
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Richard                                                       
             Jacob/Germany/IBM                                             
             @IBMDE                                                     To 
                                       wsrp-interfaces@lists.oasis-open.or 
             01/19/2005 08:41          g                                   
             PM                                                         cc 
                                                                           
                                                                   Subject 
                                       [wsrp-interfaces] Groups -          
                                       CCPP-support-draft03.html uploaded  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




The document revision named CCPP-support-draft03.html has been submitted by
Mr Richard Jacob to the WSRP Interfaces SC document repository.  This
document is revision #2 of CCPP-support.html.

Document Description:
comments from review, PublicParams approach

Download Document:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/11106/CCPP-support-draft03.html


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


Revision:
This document is revision #2 of CCPP-support.html.  The document details
page referenced above will show the complete revision history.


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.

-OASIS Open Administration


  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]