RE: exploration of non-web intent providers

Dave,

Re "Another way to extend the browser without having to update its code
would be to make use of a local device server, such as is proposed by
webinos. The local server could register a bunch of services with the
user agent.", this is what I have proposed as one approach to the integration of diverse event notification (Push) services into the Server-Sent Events spec, in addition to the current HTTP-based SSE protocol. 

Connecting to a local server which maintains a local SSE connection, while receiving and bridging events from diverse Push event sources (e.g. SMS, OMA Push, SIP MESSAGE, and various proprietary sources) will be a discussion topic at the upcoming Webapps F2F. There are at least a couple of approaches to consider, and I would further like to consider how the "provider" of such a service can be registered using Web Intents. 

The approaches include the tightly-bound case of user-agent abstracted service (what I call a "virtual EventSource server"), or the more loosely bound case of a local HTTP server which exposes an EventSource service as bridge to other Push services, with (in both cases) URL parameters of the EventSource URI being used to select various Push service features (e.g. source, content, or application ID filtering).

Thanks,
Bryan Sullivan

-----Original Message-----
From: Dave Raggett [mailto:dsr@w3.org] 
Sent: Friday, April 20, 2012 1:15 PM
To: Jean-Claude Dufourd
Cc: public-web-intents@w3.org
Subject: Re: exploration of non-web intent providers

On 20/04/12 16:07, Jean-Claude Dufourd wrote:
>>> REQ4: Device1 MUST have an http server running somewhere to put the
>>> registration and service pages.

>> I wasn't sure whether REQ4 is needed for your option 2.

> JCD: Where do you store the service page managing the intent provided by
> the Device2, service page which in option 2 is generated by an entity on
> Device1 ?

Our models are different, and in my case there isn't a service page as
such, but we could choose to expose the UPnP service description to the
web app after the user has selected device2. That is a matter of how
much we choose to support abstraction layers that hide whether the
service was discovered via UPnP or ZeroConf etc.

>> I experimented with chromium browser extensions as a means to implement
>> Web Intents along with UPnP.*This is surprisingly tricky, and indicates
>> the need for a simply means to couple web intents to trusted browser
>> extensions*. I am hoping to explore extending webkit to support this over
>> the next year.

> JCD: This is the reason behind my proposal.
> If nothing is standardized, then doing this UPnP link will be highly
> dependent on the browser, whereas if the UA itself is a UPnP service, with
> the service description I propose, then interface with the UA is the same
> as interface with other services, and it will work across browsers.

If we want browsers to work with today's UPnP devices, then there will
need to be some client side code that understands UPnP advertisements
and the associated service descriptions.

For the intent matching to work there would need to be a map from the
intent names e.g. for TV and print to the corresponding UPnP
terminology. Given that, it doesn't seem unreasonable to do the next
step and expect the UA to connect the services via message ports.

Another way to extend the browser without having to update its code
would be to make use of a local device server, such as is proposed by
webinos. The local server could register a bunch of services with the
user agent. This leaves open the question of informing the web intent
system that an given intent provider offers a message service rather
than a web page that the browser needs to load. That sounds to me like
information that would be provided through the registration mechanism.

The web intents registration mechanisms seems a little vague to me at
this point. I understand how an intent provider could be registered if
you as the end user visit the associated website. However, what about
when you need to search for intent providers. Do we have a better
solution that using a regular search engine and following the links it
returns one by one? That is putting a big burden on end users! When it
comes to local discovery, the notion of a registered intent broker is
interesting. The browser would ask that broker for intent providers
matching a given intent. The webinos local server (aka PZP) could act as
an intent broker. It is certainly worth thinking about.

-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Monday, 23 April 2012 00:29:39 UTC