Re: Drop work on DAP charter v3?

SULLIVAN, BRYAN L wrote:
> I've tried out the Javascript QR code reader demos and it's true they kind of work sometimes on laptops, but so far I have not been able to get them to work on mobile phones.

It seems this is due to the lack of timely autofocus you mention below? 
Or do you think there are other issues that prevent capturing QR codes 
on mobile? Interested to hear about your experiments in this area.

> There are various complexities (e.g. Autofocus) that don't work well in current getUserMedia implementations for example,

We recently patched our getUserMedia implementation to autofocus a media 
stream against the current scene every X seconds. X is currently set at 
10 but we're going to continue experimenting with that number. That 
should fix the autofocus problem and make QR code reading more accurate. 
It should already be available in current Opera.Next Desktop/Mobile 
releases.

> beyond that there are code translation functions that can't be delegated to JavaScript alone (at least for indirect codes), etc.

What functions did you have in mind that can't be implemented in JavaScript?

> For these reasons it is beneficial to have an API that can invoke a local code reader client which has been designed specifically for those functions. I am currently involved in discussions in the OMA on the requirements for such a Web Runtime API, and possible design approaches to integrate it with a HTML5 browser based UI. I would like to bring that discussion into W3C as soon as possible, so would appreciate the QR code reader API to be considered in DAP or the System Level API WG charter.

In the mean time it seems like we should experiment in JavaScript and 
are likely to require JS shims/fallbacks using getUserMedia for 
unsupported browsers in the short/medium term. Perhaps indefinitely.

--

Our QR code reader proof-of-concept implementation can be seen @ 
http://www.shinydemos.com/qr-code/. We're getting fairly close to doing 
everything we need to do wrt QR code capture without requiring a 
dedicated API.

- Rich

[1]

Received on Wednesday, 23 May 2012 10:50:03 UTC