- From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Date: Thu, 24 Nov 2011 17:48:07 +0100
- To: Dave Raggett <dsr@w3.org>
- CC: Paul Kinlan <paulkinlan@google.com>, public-web-intents@w3.org
On 24/11/11 17:43 , Dave Raggett wrote: > On 24/11/11 16:02, Jean-Claude Dufourd wrote: >> This is exactly why I said that we may have a different definition of >> discovery. >> You seem to be interested mainly in discovering services that are not >> yet known but are directly accessible in the environment of the >> current device (read: that do not need an (IP) address to be talked to): >> - peripherals connected to the current device; >> - optional software installed on the device... >> The Home Network TF is only interested in discovering services >> elsewhere on the network, on devices unknown to the discoverer. >> >> And even your version of discovery is outside the scope of Web >> Intents if I am not mistaken. > > I suspect that this is a misunderstanding. The intent element is just > one means for registering services. The UA could also perform > discovery over UPnP either as part of the browser or via an extension. JCD: Yes, but that would be outside the scope of the Web Intents specification even if that would be a valid use of the spec. Best regards JC > This results in a mapping from intents to services and would normally > occur in the background. If it would help, I could produce an addon > for Firefox or Chromium to demonstrate this (this would not be ready > until end December). When the web app requests a binding for a given > intent, the UA displays a dialog for the user to pick a matching > service. This dialog could be dynamic in the sense that the UA could > perform UPnP (or Zeroconf) queries for new services rather than just > rely on what services have been seen prior to the dialog being > displayed. Note that that is more important for Zeroconf than for > UPnP. The user confirms the selection, and the binding is passed back > to the app as an Intent object. The app sets the function for the > start of the activity, and that function has access to the service > metadata on the Intent object. This metadata should be sufficient to > establish a communication path with the service. > > An open question is how the UA or UA extension relates intent strings > to the service identifiers used by UPnP services. I believe that this > is out of scope for the Web Intents API, but please correct me if I am > wrong. > >> On 24/11/11 16:01 , Paul Kinlan wrote: >>> We don't have any addresses in the discovery process, the >>> webintent.org/share urls are a simple string that is used to allow the >>> UA to know the task the user want't to achieve. It could be just a >>> plain string "read-temperature" >>> >>> Our current documents describe the process of registration that can be >>> detected by the UA, via the parsing of the intent tag, but we haven't >>> said that they only way that a UA can know about a service is via only >>> the intent tag. >>> >>> As Greg said earlier, we will be able to list the intents a service >>> supports via the chrome extension/app mechanism - this is not done via >>> the intent tag detection and is still conformant with the spec we had >>> defined. -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Thursday, 24 November 2011 16:48:39 UTC