RE: Comments on Device Description Repository Requirements 1.0

Hello Tim, first allow me to express what an honor it is for me to address
issues raised by the great Tim Berners-Lee, the inventor of the World Wode
Web.


My name is Luca Passani and I am the architect of a popular open-source DDR
implementation called WURFL. 

I have suggested that the TAG and DAWG look at this spec.

> a) 2.11.  Use-case 1. Utilization of device description information  
> from the DDR
>
>  The requirements don't say anything about cacheing.
>
>    If really every single request for content from a phone goes  
>through the flow show, the server will be under intolerable load and  
>a complete bottleneck.  It is clearly necessary for the content  
>provider, or an intermediate node, to keep a cache of previous  
>requests. This requires the cache control facilities

In DDWG we had the issue of caching very clear, but we felt that this was an
implementation detail. There are different ways to do caching, all
legitimate depending on the context. We focused on the interface to the DDR,
which would allow developers to switch from one complying DDR to another.
I find your point very valid, though. We should probably acknowledge that
DDRs operate at two levels: low level (with RDF-based device description
a-la UAprof) and high level (with APIs for all the popular programming
platforms). In this context, caching would be handled at the high-level, in
which information is cached locally either by caching the profiles or by
importing the data into a RDBMS.


>b) An unwritten requirement is that new technology is not invented  
>where existing technology exists.
>
>(For example, HTTP caching provides the facilities necessary (proxy  
>architecture, cache read-through, expiry time, etc) and do providing  
>the DDR lookup over HTTP clearly allows the client architecture.   
>SPARQL may provide a suitable protocol)

the caching at this level is probably too unreliable to be responsive enough
for most uses. Whatever the mechanism to retrieve device profiles at the
lowest-level (say, UAProf) is, the data would have to be available to the
multiserving framework in a matter of milliseconds for all the requests
(with the possible exception of the very first). Caching at the level of
HTTP proxies can hardly achieve this and even if it did, it would imply that
the profile is parsed and managed for each request, which would also be not
good enough.

> c) "The Device Vendor develops, manages (e.g. updates existing device  
> profiles when devices are upgraded)". That's interesting.  I  
> understood that in the past, device vendrors have nor always been  
> forthcoming with such information.  Will the DDR only use vendor  
> data, or possibly third party data?  Clearly vendor data makes more  
> sense, so long as it is provided.  Presumably the DDR architecture is  
> not affected by this choice.

The way it works today (and this applies to both commercial DDR vendors and
open-source efforts) is that UAProf profiles (provided by device vendors)
are the main source of device information. In addition to UAprof, DDR data
is enriched with information coming from all kind of different sources:
proprietary test suites, published documentation, anecdotal evidence, and
even "inheritance" (for ex, a device from this or that vendor will probably
support this or that format).
DDR typically fix erroneous UAProf data *and* add data of their own which
are not contemplated by UAProf. 

Thank you

Luca Passani

Received on Thursday, 4 May 2006 08:58:24 UTC