W3C home > Mailing lists > Public > public-web-intents@w3.org > January 2012

Comment on W3C Web Intents specification draft proposal (was RE: Mapping WebIntents to Network Service Discovery API)

From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Tue, 10 Jan 2012 15:27:37 +0100
To: Greg Billock <gbillock@google.com>, WebIntents <public-web-intents@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D6338037E@seldmbx03.corpusers.net>
Hi Greg,

You refer to http://lists.w3.org/Archives/Public/public-web-intents/2011Dec/0043.html, which I guess is the first version of a W3C Web Intents specification.

I read it quickly. Even though discussions are ongoing I would like to submit some initial comments:

* Clarify which sections that are normative vs non-normative.

* Section1, 2nd paragraph: "(....i.e. "share" or "edit"...),I guess it should be (e.g. "share" or "edit").

* Section 1.1, last example: "window.intent.postReply(getImageDataURI(...));". Should be ...postResult...

* Section 4, User Agent Behavior, 3rd paragraph: Miss statement/example on dynamic registration on discovered services, e.g. services on UPnP or Bluetooth connected devices.

* Section 5.3, Persistent connections: "A third is returning a MessagePort to the client which can be used for subsequent communication." . This wording implies that the service returns the MessagePort that is returned as result data. However, according to mail discussions it seems as the preferred solution is that the Client allocates the MessagePort that is sent as payload data to the Service. It would also be good to elaborate more and include examples on all the methods for achieving persistent connections. Should this be part of a normative section or stay informative?

Regards
  Claes



> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com]
> Sent: den 10 januari 2012 02:09
> To: WebIntents
> Subject: Re: Mapping WebIntents to Network Service Discovery API
> 
> On Mon, Jan 9, 2012 at 12:53 PM,  <Cathy.Chan@nokia.com> wrote:
> > [...]
> > Actually, that makes it a rather different use case than what I
> believe the
> > UPnP-minded folks have in mind. We should consider the UPnP devices
> as legacy
> > devices with no web capabilities whatsoever. (They use HTTP etc. but
> in a
> > predefined manner.) I would imagine the UA, or an extension to the UA,
> to act
> > as a bridge between the UPnP protocols and the web protocols, but I
> doubt if
> > the UA/extension would go so far as serving up a full-blown web based
> service
> > including the progress/animation/status/ads/whatever you pictured in
> 5b.
> 
> I wrote up an approach to UPnP device interaction here [1]. It takes
> the approach that
> while it may be the province of the User Agent to speak UPnP, Web
> Intents should not
> attempt to be a bridge protocol between UPnP and web content. There
> are quite a few
> use cases that can be solved in this way, but there are some that are
> much trickier,
> if not impossible. Whether that means Web Intents is a poor match for
> what web content
> might want to do with UPnP devices I'm not sure. I don't have a good
> handle on the
> relative qualities of the use cases.
> 
> 
> 
> > So, basically we have two different schools of thoughts here. One is
> that the
> > Site only needs to know about the high-level actions such as share
> and print,
> > and things like UPnP is just the low-level way of accomplishing that
> > [typically one-off] task, and that the Site doesn't care whether it's
> UPnP or
> > AppleTalk or whatever - just print the page. The other is that the
> Site is
> > fully aware of and even designed for using UPnP to engage in a
> longer-term
> > relationship with a UPnP device. Imagine a Site that lets you control
> your
> > UPnP Blu-ray player. It needs feedback from the player (e.g. through
> events)
> > to be able to show you the current playback position or
> enable/disable the
> > play/pause button based on the current playback status.
> 
> This is a great phrasing of the crux. Thanks! I currently come down
> wanting UPnP to
> remain the province of the User Agent, but that's partly because I
> don't have a
> good grasp on what the eventing properties are that would need to be
> implemented,
> and what functionality they'd enable. One thing I'm missing is a good
> delta
> understanding between the Web Intents proposal as we currently have it
> written up
> (at [2]) and a version of Web Intents that fully bridged UPnP. What
> would that look
> like? Or will it fit into the existing API somehow? If so, how?
> 
> [1] http://lists.w3.org/Archives/Public/public-web-
> intents/2011Dec/0043.html
> [2] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
Received on Tuesday, 10 January 2012 14:38:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 10 January 2012 14:38:54 GMT