- From: Sam Sotiropoulos <sam@sotiropoulos.com>
- Date: Thu, 4 May 2006 14:51:41 -0700 (PDT)
- To: "Tim Berners-Lee" <timbl@w3.org>
- Cc: public-ddwg@w3.org, "tag" <tag@w3.org>
Mr. Lee, Just a few questions: I understood that you were against 'breaking the net' so I am curious to see your comments on this spec. Is this extra layer of complexity designed to cater to a sub-category of internet enabled devices really needed? Can we not code according to standards and expect that the existing infrastructure and agent detection tools be a sufficient model of approach? Amiably, Sotiris Sotiropoulos > > I have suggested that the TAG and DAWG look at this spec. > > Glancing through > http://www.w3.org/TR/2006/WD-DDR-requirements-20060410/ > the following things occur to me. > > A requirement: > > 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 > > and two informal thoughts: > > 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) > > 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. > > Tim > > >
Received on Friday, 5 May 2006 04:07:15 UTC