W3C home > Mailing lists > Public > public-bpwg@w3.org > July 2009

RE: MWABP: Revised text for Device Capability Detection.

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>
Message-ID: <E6C1742D0D12A447A5FBEAFC8E5EDAAF468F8423C9@NOK-EUMSG-04.mgdnok.nokia.com>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:01 UTC