Ideas for API design in Web and TV service environment

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

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

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

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

Thanks,
Bryan Sullivan | AT&T