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

On Wed, Dec 16, 2009 at 9:09 PM, Ian Hickson <ian@hixie.ch> wrote:

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

Fundamentally I have no problem with the "author-supplied APIs" being
limited to RESTful APIs over HTTP (rather than arbitrary Javascript
interfaces).  What I'm interested in here is the ability to use this UI as a
way to "hook up" apps.  Currently we don't have a good way for one site to
say "I provide an object of type X!" while another site says "I can use an
object of type X!", and then let the user choose to connect the two in a
secure way.  In practice, either the latter site has to be hard-coded to
talk to the former, or the user has to copy-paste some sort of
URL-plus-security-token from one to the other.  I think the UI you're
imagining for device selection is also a good UI for forming these kinds of
hook-ups, so I was hoping they could share work, instead of having to solve
the same problem twice.

If there's a way to do this sort of thing with existing standards that I
don't know about, please point me in the right direction.


> > 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"?
>

Maybe ".object"?  I don't know what words are already reserved.