Re: intents broker == user agent ?

On Wed, Nov 23, 2011 at 1:36 PM, timeless <timeless@gmail.com> wrote:
>
> 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.

Yes. Perhaps we should give these two usages of "discovery" separate
names. The 1-B form is an advertisement for the UA. The way I'm using
"client" and "discover" above means the web page that calls
navigator.startActivity (or some other invocation). That's the kind of
discovery we haven't envisioned making possible.

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

I believe we are in agreement here.

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

What mechanism do you think would be preferable to MessagePort? The
current API [1] looks pretty capable, especially with the intention of
adding ArrayBuffer binary support. That makes translation to arbitrary
protocols, including those of non-web-native equipment, a lot more
achievable.

>
> > 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.
>
> Greg:
> 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].

Done.



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

The way we've been envisioning intents, they're as brokered RPC.
That's really great for certain use cases, but if we want to use the
same mechanism for extended interaction with a particular endpoint, we
need to account for that. If we can do so without causing problems for
the brokered use cases, I think that would be a great thing to
consider. So far we've anticipated that the Web Intents mechanism
would be great for establishing such connections, but that other
elements of the platform would be better for the continued
interaction.


[1] http://www.w3.org/TR/html5/comms.html#messageport

Received on Monday, 28 November 2011 18:35:46 UTC