until we don't have a ML....quick comments.
I would ask people more familiar with intents to correct me if I'm wrong
On Thu, 10 Nov 2011 17:20:46 +0100, Clarke Stevens
<c.stev...@cablelabs.com> wrote:
Dominique,
Your example below is very helpful. I have a couple of follow-up
questions:
* I want a single web page with the UI exposed to the user. The user
should not see any additional tabs or browser windows (except perhaps a
pop-up child dialog listing available relevant services). Is this
possible?
IIUC all the examples with windows and tabs are just examples. How the
choice is presented to the user is an implementation details and this
allow the browser manufacturer to customize the view based on your needs
(e.g. browser embedded in TVs often to not have tabs or not even a chrome)
* The UI web page should not have any information about what devices are
discovered in the local network until given explicit permission by the
user. This would prevent most snooping scenarios. Is this possible?
I think that if we want to go "the intent way" the idea is that the web
page NEVER have information about the devices.
I think is good to preserve privacy here. Before exposing this to an
application we need to make sure is actually needed.
* The UI web page should be able to handle devices appearing and
disappearing at random times and be notified of such via events. Is this
possible?
I'm wondering if tḧis is actually needed. If you handle the "picker"
natively, I think also this aspect will have to be handled by the browser
and not exposed to the application.
The only thing that needs to be handled is when you are not able to
communicate with a service, but that would be equivalent to a web based
intent not being available (e.g. becuase network is down or the web server
is down or whatever)
* The devices and services discovered should be determined by very
specific service types within existing protocols (e.g. An AV rendering
device as opposed to a content server). Is this possible?
I think this is covered by intents.
* Could multiple protocols be supported for the same service (e.g. A
Zeroconf DAAP server and an UPnP CDS as sources for the same directory
tree window on a UI web page)?
Also this is probably not part of the web intent discussion. Web intents
provide the general infrastructure. How do we map specific services on
intent should be handled by another spec and probably discussed in DAP (or
not?). We have 2 options here: have different intents for different
protocols or one intent that try to cover all similar services. The first
one is easier to implement, the second is much more handy for applications
developers. I'm starting to think that we should try to go for the second
option. If we go for that we will have to address the problem of
differences in capability between different (similar) services/protocols.
/g
Obviously, we'll need to go into all of these questions and more in
detail
as we explore this, but I just wanted to get some high-level feedback on
some cases that may not be good fits for the Web Intents usage model.
Thanks,
-Clarke
On 11/10/11 8:58 AM, "Dominique Hazael-Massieux" <d...@w3.org> wrote:
Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :
Hi
a.) to register a URL endpoint as an intent provider the user must
visit
a web page (presumably hosted by the target device itself) and capture
the intent registration from that page before that intent provider can
be used within the UA.
My understanding is that this is not a MUST at all, but the way
Web-based services can be added by a user.
For a local network approach, my take would be that the browser would be
doing the discovery, and possibly offer the user to add local services
to the list of available providers when such a service matches the
requested intent.
Typically, a "gallery" intent (i.e. requesting a list of medial files)
would make the browser list local media galleries (from UPnP) in
addition to the registered Web services (e.g. your on-line photo
albums).
b.) to then subsequently use a registered intent provider the concept
is
to open that provider, again as a web page in a seperate tab within the
UA. From here we can then establish a bi-directional web messaging
channel on which we can send and receive messages to communicate to and
from that web page that is representing the current local service.
I think the Web-page-in-a-separate tab is also an optional aspect of Web
intents; the browser could serve as a broker between the local-network
service and the Web page.
Perhaps someone could take the time to describe exactly how a user
could
communicate with an existing TV device in their home from a web browser
supporting web intents based on the above requirements?
Here is a rough sketch:
* user hits a Web page that wants to load a picture from his gallery
* that Web page asks for an intent for media gallery
* the browser shows to the user the list of services that can provide
media galleries; having detected that there are such services on the
local network, it includes these services in the list
* the user wants to pick a picture from the gallery hosted on his TV, so
picks the TV set in the list of services
* from then on, the browser turns the messages sent by the Web page via
postMessage() into UPnP requests that the TV set can respond to, and
also turns the responses into messages that the Web page can deal with.
Dom
--
Giuseppe Pascale
TV & Connected Devices
Opera Software
