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

Here is the w3c device independence note I mentioned:

http://www.w3c.org/TR/di-dco/

It may be worth observing that public parameters can be used for such existing schemes while directly supporting CC/PP in 2.0.

Regards,

Andre

From: Atul Batra [mailto:atul.batra@Sun.COM]
Sent: 02 February 2005 16:43
To: Richard Jacob
Cc: wsrp-interfaces@lists.oasis-open.org
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

wsrp-interfaces message