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

Re: <device> proposal (for video conferencing, etc)

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 17 Dec 2009 05:09:31 +0000 (UTC)
To: Kenton Varda <kenton@google.com>
Cc: public-device-apis@w3.org
Message-ID: <Pine.LNX.4.62.0912170443250.15825@hixie.dreamhostps.com>
On Wed, 16 Dec 2009, Kenton Varda wrote:
> 
> However, I notice you have a note suggesting limiting the scope of the 
> tag to audio/video streams.  I think such a limitation would be pretty 
> disappointing.  There are an infinite number of ways that this mechanism 
> could be useful for things other than audio/video.  A couple random 
> examples:
> - You hint at the idea of exposing a USB media player's file system, 
> which is a great example:  this would allow someone to write something 
> like iTunes purely as a web app, complete with the ability to populate 
> the user's media player.

I agree that it's an interesting feature to expose; the question really is 
whether it should use the same element (and thus in-page UI) as the camera 
case. We have had mixed results in the past with overloading elements -- 
<object> for example has been pretty much an unmitigated disaster; <input> 
has been a mixed bag, with well-known complications arising from the 
overloading but also the benefit of forward-compatibility; <link> has been 
pretty much a success.


> - Lots of sites ask users for gmail login credentials in order to access 
> their contact list.  It would be better if the capability to access the 
> contact list could be treated as a "device", and I could give a site 
> access to my gmail contact list simply by hooking it up like any other 
> device.

That seems a little scary. I'd much rather have GMail's contacts expose a 
postMessage()-based API, or use something like WebSockets, than have GMail 
have to interact with a <device>-like mechanism. Having to interact with a 
<device>-like mechanism means registering, defining a protocol, etc, which 
is distinctly non-trivial and doesn't scale to supporting many other 
features that would need thing kind of thing (e.g. exposing a Twitter 
stream, or Facebook friends, or an Amazon wishlist, or a calendar, or...)


> A couple trivial nitpicks, neither of which is terribly important to me: 
> - I think the name "data" for the device object is a little misleading, 
> since it's actually a stateful object, not just raw data. - The tag name 
> <device> could itself be confusing when this is used for non-device 
> objects, as I would like to.  For example, a contact list capability is 
> not really a "device".

I'm very skeptical of extending this to the point of covering even 
arbitrary author-provided APIs. I don't really understand what benefit it 
has over what we have now.

What would you suggest instead of ".data"?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 17 December 2009 05:09:59 GMT

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