[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(). <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]