RE: MWABP: Revised text for Device Capability Detection.

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> 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.

	 

	 

	 

	[...]