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

Thank you for these comments, Claes.  I just sent a request to have a
Web Intents TF component created in the W3 bugzilla.  Once that's
created, I'll file some of these issues as bugs.  For the rest, I'm
fixing the draft right now.  I'll CC you on the bugs once they're
created.  I'll send a note to the list once the component is created.


On Tue, Jan 10, 2012 at 6:27 AM, Nilsson, Claes1
<Claes1.Nilsson@sonyericsson.com> wrote:
> 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.
>

Will file bug.

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

Fixing.

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

Fixing.

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

Will file bug.

> * 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?
>

Will file bug.

Thanks,
James

>
>
>> -----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 Monday, 16 January 2012 22:59:29 UTC