W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Re: Camera/Caputre API (was: DAP Roadmap, priorities)

From: Andrei Popescu <andreip@google.com>
Date: Tue, 24 Nov 2009 12:41:12 +0000
Message-ID: <708552fb0911240441q48706730j29e79db3b0e47ab8@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Robin Berjon <robin@robineko.com>, Dominique Hazael-Massieux <dom@w3.org>, Ingmar.Kliche@telekom.de, public-device-apis@w3.org
On Tue, Nov 24, 2009 at 5:30 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 18 Nov 2009, Robin Berjon wrote:
>>
>> The reason I'm interested in looking at (2) is because I'm concerned
>> that we may be trying to pile too much onto <input>  we could, after
>> all, have had <input type='location'>. If the geolocation model works,
>> we should build on it. This doesn't prevent the <input>-based access 
>> in fact for the capture API I like it very much because it makes a lot
>> of sense semantically here. We can do both  so long as we build on
>> existing models I feel rather safe that we're not doing weird stuff and
>> that we're benefitting from improvements that can be made to other parts
>> of the stack that rely on these approaches.
>
> We tried <input type=location> before using an async API. It wasn't quite
> the right fit for various reasons (in particular, it's not clear what the
> user interaction would be -- there's no location to select, generally,
> it's just a recurring event when the user moved).
>

That's right. I explained the design decision behind the async API here:

http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0076.html

Andrei
Received on Tuesday, 24 November 2009 12:41:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT