RE: Any CC/PP App servers in the market

Interestingly ArgoGroup have some information about the UAProf profiles for
certain phones on their website. Shame they don't have the URIs for the
actual profiles themselves though. 

See http://devzone.argogroup.com/c5_0.html

Mark Butler
R&D Engineer
HP Labs Bristol

-----Original Message-----
From: Vidhya Gholkar [mailto:vidhya.gholkar@argogroup.com]
Sent: 15 August 2001 22:45
To: Butler, Mark; babe@hotmail.com
Subject: RE: Any CC/PP App servers in the market


Argogroup does provide a UAProf server - this is provided as a part of
its UbiquinoX Contentmaster application server product. Argogroup's
product provides significantly more information about device capability
then UAProf. The data for this server is obtained by a global device
profiling capability.

Vidhya

-----Original Message-----
From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com]
Sent: 15 August 2001 10:03
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.p
df)
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 Thursday, 16 August 2001 06:52:40 UTC