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 Tuesday, 30 June 2009 09:23:48 UTC