Re: Ideas for API design in Web and TV service environment

Hi Bryan,

On Wed, 21 Sep 2011 22:03:46 +0200, Bryan Sullivan <blsaws@gmail.com>  
wrote:

> Some thoughts, possibly ahead of the discussion in this area, but offered
> for consideration nonetheless. The WG to address these aspects is TBD I
> understand, but I think it would be helpful to dialog on general  
> approaches
> to API design to set some expectations and common goals.
>
> Re the approach to API design for use by Web apps in a Web and TV service
> environment, we should consider, for the APIs that we find the need to
> define (assuming that we in the end *do* need to define APIs, i.e. they  
> are
> essential and not already available), here are some thoughts. Our  
> objective
> in this is to keep the impact to the Web User Agent (e.g. browser or Web
> runtime) as minimal as possible, both to speed development and
> deployment/service experience, and to ensure flexible distribution of
> enabling functions (e.g. discovery).
>
fully agree. these are indeed the design goals behind our proposal.
http://people.opera.com/richt/release/specs/discovery/Overview.html

Could you check the draft and see if it matches your expectations?

Discussion on this proposal is already started on DAP mailinglist.
I think that, to avoid confusion, is good to keep the discussion on the  
proposal on that list,
so feel free to reply there.

Few comments inline:

> Access to attached/networked devices is possible through various  
> approaches
> and levels of abstraction. I provide below an example set of options  
> (there
> are others), and just some that I think should be considered and selected
> (or not) based upon a consensus on the rationale for or against the
> approaches.
>
> For example for the purpose of discovering what devices are available to  
> the
> Web app to integrate with:
>
> 1) Direct, non-abstracted, accessed though Javascript: a low-layer  
> protocol
> (e.g. SSDP) can be the source of events to a Web app delivered through a
> generic event service such as EventSource. This can have a very limited
> impact on the User Agent. We are prototyping for example an EventSource
> extension for SMS and OMA Push (as described informatively in the
> EventSource spec), and these new event types can be delivered and  
> processed
> by the application in their raw form, without impacting the browser for
> complex protocol adaptation/abstraction. The same approach can be used  
> for
> device discovery. For example, using EventSource with a new source type
> could be expressed as:
>
> es = new EventSource("ssdp:"); // deliver all SSDP events
> es.addEventListener("ssdp", function(event) { /* process event */ },  
> false);
>

we may want to avoid a too low-level API otherwise it gets tricky to  
enforce security.
I still think discovery should be mostly controlled by the user agent.

> 2) Abstracted access through URL scheme handler for a "discovery"  
> service on
> the platform: using XHR, an EventSource connection can be made to a URL
> scheme handler on the device (e.g. discovery://?deviceType="camera"),  
> which
> then delivers the events using normal EventSource events (with event  
> data to
> be defined, abstracting whatever discovery event occured). This can have
> very little impact upon the User Agent, leveraging another client on the
> platform which is the local handler for the URI scheme, and is able to  
> issue
> events to the User Agent through as normal a means (e.g. HTTP stack?) as
> possible.
>
> 3) Abstracted access through a discovery service, on the platform or some
> other device in the local network: using normal HTTP-based URLs in XHR or
> EventSource, a discovery service existing somehere in the local network
> (event on the host device) can be accessed and used for delivery of
> abstracted discovery events. This would allow for example a home gateway  
> to
> act as a discovery service provider for devices in the home, exposing the
> informaton as REST resources or EventSource resources. This would have  
> zero
> impact on the User Agent. The main challenge seems to be how to discovery
> the discovery service resource address (URL).
>

If you give up on the idea of being able to do everything via the browser  
with standard API, I think you already have what you need to do this,  
discover you service via UPnP (using an extensions or plugin) and point  
the browser to it. Our goal though was to have a standard API that do not  
require plugins or other components to be involved.


> 4) Abstracted access through Javascript: low-layer protocols can be  
> handled
> by the User Agent and made available to Web apps through Javascript
> interfaces specific to the purpose e.g. of discovery, attachment,
> interaction with attached/networked devices. This has a higher impact on  
> the
> User Agent, as it has to do the protocol handling directly (or through  
> some
> other underlying platform API). For example:
>
> var deviceAvailableNotification = new
> DeviceAvailableNotificationEventSource();
> deviceAvailableNotification.addEventListener('camera', function (event)  
> { /*
> do something with the new camera */ }, false);
>
yes, it has an impact, but also benefits. But we should try to keep it  
quite generic (i.e. we discover 'services', whatever those could be)

/g

> Thanks,
> Bryan Sullivan | AT&T


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Wednesday, 28 September 2011 10:24:40 UTC