Re: Any CC/PP App servers in the market

Actually, they create a device class... Same problem as before. It is always the
edge cases that get you.

Olivier Rovellotti wrote:

> Mark,
>
> Thanks for the pointers, they both are very interesting approch, and
> specially the morphis effort.
> The information provided by Argogroup is good althought very incomplete.
>
> The XML profiles solution of (http://www.morphis.org/) have a lot more to
> offer so far.
> I am sorry to say that I would be more keen to parse their XML descriptions
> of a few hundred devices then one or two UA-Prof description :-(
>
> It seems that for the CC/PP-UAProf to be succefull is would really reuired
> more profiles to be available
>
> Sorry to state the obvious
>
> -----Original Message-----
> From: www-mobile-request@w3.org [mailto:www-mobile-request@w3.org]On
> Behalf Of Butler, Mark
> Sent: Wednesday, August 15, 2001 6:03 PM
> To: 'cafe babe'; www-mobile@w3.org
> Subject: RE: Any CC/PP App servers in the market
>
> 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

--
++++++++++++++++++++++++++++++++++++
  Johan Hjelm, Senior Specialist
     Ericsson Research Japan

  Read more about my recent book
http://www.wireless-information.net
************************************