Re: Any CC/PP App servers in the market

  Let me add a bit of "me-too" information here. We developed a 
"simplified" CC/PP - the argument being that a device category 
description is sufficient for most content transcoding purposes rather 
than gory descriptions of an individual device's capabilities. We 
implemented an apache module that would parse the CC/PP URL to infer the 
device type, and then use XSLT to transcode (and cache) a device 
specific version of the requested page. This work was published in the 
proceedings of the IEEE ICPP workshop on Mobile Computing and Wireless 
Networks in Aug 2001, and is accessible on-line from our web page.

							Anupam Joshi

Butler, Mark wrote:

> As far as I know there are no CC/PP enabled app servers on the market -
> current servers use the User-Agent string and then often use their own
> device capability database. For an example of this, see the device.xml file
> in the Morphis open source device transcoder (http://www.morphis.org/) or
> the BrowserImpl.xml file in the Cocoon 2 framework
> (http://xml.apache.org/cocoon). 
> 
> Furthermore as far as I am aware, no-one seems to have considered whether
> the proposed CC/PP (http://www.w3.org/TR/NOTE-CCPPexchange) and UAProf
> (http://www1.wapforum.org/tech/terms.asp?doc=WAP-248-UAProf-20010530-p.pdf)
> protocols will be compatible with the current HTTP servlet API. I'm
> currently trying to determine whether current app servers can use the
> proposed CC/PP and UAProf protocols or whether this will necessitate changes
> to the base servlet API. Personally I think it would be better to use a
> protocol that is compatible with the javax.servlet.http API, and derive a
> new API(s) from that specifically for CC/PP and UAProf. 
> 
> Specifically current servers such as Tomcat will respond to some CC/PP
> requests. There are two problems: Firstly the HTTPex numerical namespace
> seems to add unnecessary complexity - perhaps someone from the CC/PP working
> group could explain the rationale behind this? Secondly including carriage
> returns in the XML file associated with a profile-diff causes problems with
> the current servlet API. For example if I send the following CC/PP request
> to a simple HTTP request snooping servlet on a Tomcat server
> 
> GET /ccpp/headers/index.cgi HTTP/1.1
> Host: localhost
> Opt: "http://www.w3.org/1999/06/24-CCPPexchange"; ns=19
> 19-Profile: "http://www.aa.com/hw", "http://www.bbb.com/sw",
> "1-uKhJE/AEeeMzFSejsYshHg=="
> 19-Profile-Diff-1: <?xml version="1.0"?>
>  <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
>              xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
>              <Description ID="SoftwarePlatform" PRF:Sound="On" />
>          </RDF>
> 
> Then I can successfully retrieve the file from Tomcat once, but subsequent
> retrievals or not always possible as Tomcat reports
> 
> Parse error, missing : in
> mlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
> 
> This problem can be avoided by omitting carriage returns in the enclosed
> XML. However this requirement is not mentioned in either the CC/PP and
> UAProf protocol specs! The request above does not cause a problem for Apache
> with a CGI HTTP request snooping Perl script, but I suspect other servers
> using the servlet API will have similar problems. 
> 
> Of course once your server has got the profile, then there's the problem of
> what to do with it! This also needs "further development" just like
> vocabularies. Stuart Lewis, a student at University of Wales at Aberystwyth
> (sdl@aber.ac.uk) has a project report that discusses this. I've just
> finished a technical report that investigates implementing HTTP/1.1 content
> negotiation for CC/PP and UAProf using the JENA RDF API (see
> http://www-uk.hpl.hp.com/people/bwm/rdf/jena/index.htm) that should be
> published externally this month. Another comment to the CC/PP working group:
> please could you start keeping track of these resources in a similar way to
> the RDF working group? 
> 
> Once a servlet API is defined, I think the next step would be to add CC/PP
> support to open-source frameworks like Cocoon, Struts, and Jetspeed (see my
> technical report at http://www-uk.hpl.hp.com/people/marbut/ for more details
> of how these frameworks can be used for device independence). They already
> try to address the problem of content adaptation, so it makes sense to use
> them to demonstrate how CC/PP can be used to provide content to multiple
> devices. 
> 
> Incidentally feedback on my comments on HTTPex, servlet APIs etc from the
> CC/PP working group is welcome!
> 
> Mark H. Butler
> HP Labs Bristol
>  
> -----Original Message-----
> From: cafe babe [mailto:cafe_babe@hotmail.com]
> Sent: 15 August 2001 16:34
> To: www-mobile@w3.org
> Subject: Any CC/PP App servers in the market
> 
> 
> Just curious to know, are there any commercially available Application/Web
> servers in the market that are capable of using the CC/PP information in a
> client request to generat customized content for a client.
> I remember seeing some CC/PP classes in Jigsaw the W3C web server. BEA
> Weblogic mentions something about device profiles but I am not sure if it
> uses CC/PP for content customization.
> Quite a few  Application server vendors(Oracle,IBM,BEA to name a few)  in
> the msrket today say that they are capable of customizing content for all
> different kinds of devices(phones,PDAs,TVs etc) and that they are extensible
> to support any new devices in the future. What I am not clear is that do
> they mean that they can support any device that can render XHTML/HTML/WML,
> in whuch case the HTTP "Accept" header would be sufficient, or they mean
> that they can use a CC/PP kind of mechanism to do further customization
> based on other parameters like display size, media support etc.
> Inputs on this would be really appreciated.
> Thanks
> 
> 
> 
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>

Received on Wednesday, 15 August 2001 13:35:25 UTC