W3C home > Mailing lists > Public > public-web-intents@w3.org > November 2011

Re: intents broker == user agent ?

From: timeless <timeless@gmail.com>
Date: Wed, 23 Nov 2011 16:36:47 -0500
Message-ID: <CAACrNNex=sguF_VZzYGwoqmR+yJfjqs5qhT_AWq5yT9hc4iJcA@mail.gmail.com>
To: WebIntents <public-web-intents@w3.org>, Greg Billock <gbillock@google.com>
On Wed, Nov 23, 2011 at 3:56 PM, Greg Billock <gbillock@google.com> wrote:
> On Wed, Nov 23, 2011 at 10:48 AM, timeless <timeless@gmail.com> wrote:
>> discover and communicate.
> This perhaps could bear more discussion. The way we currently think about
> intents, the client doesn't discover who handled the intent.

In §1-B [1], there is a way for a UA to Discover _some_ *web based*
Partner Providers. This isn't a way for a Client to Discover who
handled the intent, but it's still from my perspective a Deliverable.

In §1-C [1], we're talking about communicating, and it enables some
indirect communication between a Client and a Partner Provider with
the assistance of a User Agent. This is also a Deliverable. For
convenience you can consider them distinct deliverables §1-B and §1-C,
but I expect this TF to deliver both. The author who was confused in
this thread should only look at §1-C and thus wouldn't be given any
Discovery, just the ability to trigger and act upon an intent.

> That is, the
> client prepares the invocation data and metadata, invokes startActivity(),
> and waits for a response.


> There may be some cases where particular intents need (or want) to
> communicate back as part of that response who it was that
> handled it, but there's nothing in the API for clients to discover "these
> are the set of services that can handle this action" or "this is the service
> the user picked to handle this intent."

Right, the API should not expose this, and we should actively
discourage this sort of data from being provided by §1-D [1] elements.

> We imagine this is the province of the user agent, and there's nothing in
> the API allowing the client to influence it or receive information about it.

> The intention is to create a firm semantics of user agency in dispatching an
> intent. The thinking is that with that model, the service can trust that the
> user was responsible for handing them some data, and the client page is
> responsible to provide all the information needed to perform the action with
> no back doors.


> Yes. As we've discussed elsewhere, there's nothing in the API proposal to
> forbid returning a persistent connection handle (MessagePort), allowing the
> client and service to exchange further messages. (And in fact we hope that
> ends up facilitating a wide range of use cases.) But it leaves the issue of
> what protocol is exchanged over such a channel unspecified.

My preference is not MessagePort because I think that'll be a disaster
for talking to UPnP or similar clients, and I really want them to
participate. This is part of why I'd rather have a way for the Partner
Provider to have access to an intent which can indirectly gateway back
to the original Client [2].

> I think what Paul is suggesting is that if there are particular protocol
> translations or definitions to establish for that which would be helpful,
> they not be in scope for the Web Intents API, but be considered separately.

Sorry, if you're going to reference someone, please do the entire list
a favor and follow the referencing system that is common to w3. I have
heavily used it in my emails to this list to enable everyone to see
how it works.

Also, since I'm calling you out, please turn off rich text messaging
in your client [3]. Paul was nice enough to comply [4].

> That would also allow them to be composed more generally with other
> mechanisms we may dream up in the future to establish, share, or persist
> messaging channels in the web platform. If we decide that Web Intents is a
> good API to establish such channels, that would be great, and perhaps
> reduces the size of the problem to be solved (or rather, more fruitfully
> segments it).


> More generally, this connection discovery mechanism allows us to envision
> a new class of web applications which could exploit protocol translations
> for MessageChannel (i.e. FTP, SSH, JDBC). Some cursory looking around didn't
> show any W3C effort around this; perhaps UPNP is a good place to start. :-)
> (I know very little about it.)

I'd really like to avoid message channels in favor of RPC (Intents).
The odds of a given device that supports UPnP being able to deploy an
arbitrary MessageChannel protocol are effectively 0. As it is, we're
asking people like Clarke [5] to write code that enables gatewaying
Intents, we shouldn't ask them to gateway additional protocols, it
creates too high of a barrier and will cause them to run away

[1] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0010.html
[2] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0036.html
[3] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0028.html
[4] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0015.html
[5] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0060.html
Received on Wednesday, 23 November 2011 21:37:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC