- From: <Sailesh.Sathish@nokia.com>
- Date: Wed, 1 Jul 2009 10:01:48 +0200
- To: <edward.mitukiewicz@orange-ftgroup.com>, <rotan.hanrahan@mobileaware.com>, <jrabin@mtld.mobi>
- CC: <adamconnors@google.com>, <casays@yahoo.com>, <public-bpwg@w3.org>
Thank you Edward, Rotan. Nothing more to add except that the implementations of DCCI were Firefox based (Nokia- MicroB on Maemo platform). Applications access properties through DCCI JS extensions. Implementations + appl demonstrated LBS based mashups (both FT and Nokia). br, Sailesh >-----Original Message----- >From: ext edward.mitukiewicz@orange-ftgroup.com >[mailto:edward.mitukiewicz@orange-ftgroup.com] >Sent: Tuesday, June 30, 2009 5:36 PM >To: rotan.hanrahan@mobileaware.com; jrabin@mtld.mobi >Cc: adamconnors@google.com; casays@yahoo.com; >public-bpwg@w3.org; Sathish Sailesh (Nokia-NRC/Tampere) >Subject: RE: MWABP: Revised text for Device Capability Detection. > >Hello Rotan, >Hello Jo, > >FWIW two interoperable DCCI implementations have been >completed and tested [1] by Nokia and Orange Labs about a year >ago - see also DCCI test suite and test results [2] for these >two implementations. > >Cheers >-EdM > >[1] >http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextClient >Interface/2008-08-13/ir/ >[2] >http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextClient Interface/2008-08-13/ir/tests/test_index.html > >-----Original Message----- >From: public-bpwg-request@w3.org >[mailto:public-bpwg-request@w3.org] On Behalf Of Rotan Hanrahan >Sent: Tuesday, June 30, 2009 5:23 AM >To: Jo Rabin >Cc: Adam Connors; Eduardo Casais; Mobile Web Best Practices >Working Group WG; Sailesh.Sathish@nokia.com >Subject: RE: MWABP: Revised text for Device Capability Detection. > >Jo, > >I am not an authority on the implementation status of DCCI, >but Sailesh (copied) may be able to comment. > >As for implementations of OMA DPE, I think our colleagues >within OMA should be able to comment on that. > >In keeping with the scope of the BP document, the likelihood >of these technologies becoming widely adopted in the field >needs to be considered. However, we may have a chicken-and-egg >situation, insofar as this BP document may itself be the >inspiration for the adoption of the technologies. > >A compromise, whereby these nascent practices are mentioned >(but not necessarily endorsed) would do the community a good >service, and may also spur the supporters of the technologies >to put more effort into ensuring their successful completion. >To ignore them could hurry their demise, and deny the >community the potential benefits. > >---Rotan. > >-----Original Message----- >From: Jo Rabin [mailto:jrabin@mtld.mobi] >Sent: 29 June 2009 22:30 >To: Rotan Hanrahan >Cc: Adam Connors; Eduardo Casais; Mobile Web Best Practices >Working Group WG >Subject: Re: MWABP: Revised text for Device Capability Detection. > >Reviewing this thread, as you might do, late on a Monday >evening I think >that: > >a) irrespective of Bruce's points on CSS Media queries in >answer to my earlier questions - imo the points raised in this >group's earlier discussions on the topic have not been >addressed, viz they are wasteful, and poorly supported. > >b) if there are any implementations of the relevant >technologies, then a footnote referencing DCCI and OMA DPE >might be justified. But given that this is a Best Practice >document rather than a Speculative Practice document I don't >think any reference is warranted today - even given the >latitude we have given ourselves ref speculation on what is >*likely* to become best practice. To reference them now would >be pure wishful thinking. > >Jo > >On 19/06/2009 11:28, Rotan Hanrahan wrote: >> Just be careful not to characterize DCCI [1] as an extension of >> JavaScript. The interfaces are intended for use by any client-side >> mechanism, though JavaScript is by far the most obvious >candidate (and >> has been the focus of the interop tests). This is why I did not make >> DCCI a sub-bullet of JavaScript. DCCI does provide a >normative binding >> to ECMAScript and a normative definition in IDL. Obviously I've been >> too deeply buried in DI/UWA work to notice the assumptions I've been >> making about other people's awareness of these subtleties. >My apologies. >> >> >> >> ---Rotan. >> >> >> >> >> >> [1] http://www.w3.org/TR/DPF/ >> >> >> >> >> >> >> >> *From:* Adam Connors [mailto:adamconnors@google.com] >> *Sent:* 19 June 2009 11:16 >> *To:* Rotan Hanrahan >> *Cc:* Eduardo Casais; Mobile Web Best Practices Working Group WG >> *Subject:* Re: MWABP: Revised text for Device Capability Detection. >> >> >> >> >> >> On Fri, Jun 19, 2009 at 10:58 AM, Rotan Hanrahan >> <rotan.hanrahan@mobileaware.com >> <mailto:rotan.hanrahan@mobileaware.com>> >> wrote: >> >> Again, I don't agree (and not just for the sake of not >agreeing, which >> certainly would not be my style). As José has pointed out in a >> separate response, the real issue is about awareness of delivery >> context (of which "capability detection" is part). To assume >that all >> delivery contexts are the same would be to deny the possibility of >> variation, which is counter to the idea of the Web (given its aim to >> available everywhere, to everyone and on every device). The >fact that >> the original Web (as implemented by Tim) was rather homogeneous does >> not necessarily mean that this is "good" and that heterogeneity is >> "evil". It was merely convenient at the time. As the Web >matured, browser diversity expanded. >> The diversity wasn't managed properly, and we ended up with various >> hacks to give the Web servers some awareness of the delivery context. >> I concede that the hacks were "not good" but the idea of >detecting the >> context in order to have the opportunity to deal with it has been >> there for a long time, intentionally. >> >> Good points. My knowledge is enriched. >> >> To address the "real point" of this thread, I will offer >some text >> that I hope will be useful for this section. >> >> Greatly appreciated. I'll drop this text into the next draft now. >> >> · JavaScript: this is the most common solution. A script >> determines the device/browser properties and either >manipulates the >> content via DOM access methods, or sends the gathered information >> back to the server via a HTTP request. Typically the delivery >> context information is gathered at the start of the >session, though >> dynamic information (e.g. the current screen >orientation) will need >> to be refreshed during the session. The Ajax design pattern makes >> extensive use of this technique. >> >> Within JavaScript the two things you can do are i) adapt on the >> device; >> ii) request the appropriate / alternative content from the server. >> I'll expand this point a little as I think the differences >could be clearer. >> >> · DCCI: the "Delivery Context: Client >Interfaces" (DCCI) is >> a recently introduced W3C specification that enables client-side >> access to device information via DOM methods. It is not >yet widely >> supported, but if adopted it will help to improve the >implementation >> and interoperability of script-based solutions as >described previously. >> >> · OMA DPE: the OMA Device Profiles Evolution is >an enhanced >> device profiles technology that will enable real-time >conveyance of >> dynamic device information from the client to the server. >> Information can include available memory, battery life, screen >> orientation, mute status etc., which together with other known >> delivery context information will greatly enhance the >possibilities >> for adaptation. The OMA DPE specification is expected to >be released >> soon. >> >> I'm not sure that "JavaScript" and "DCCI" work as sibling >> bullet-points like this... If DCCI is essentially the >addition of new >> DOM methods then it's a subset of the JavaScript >bullet-point... I'll >> have a go at rearranging to keep the text but not present as >parallel >> bullet-points and we can iterate in the next draft. >> >> Thanks for the text. >> >> Adam. >> >> >> >> >> >> - - - >> >> >> >> I offer this text as a starting point. >> >> >> >> ---Rotan. >> >> >> >> ** >> >> >> >> [...] >> > >
Received on Wednesday, 1 July 2009 08:03:01 UTC