Re: intents broker == user agent ?

On Wed, Nov 23, 2011 at 10:48 AM, timeless <timeless@gmail.com> wrote:

> On Wed, Nov 23, 2011 at 12:41 PM, Giuseppe Pascale <giuseppep@opera.com>
> wrote:
> > JC, all
> > as I understand it, Web Intents is just a framework that allow
> application
> > to "discover" other application via the mediation of the UA.
>
> 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. 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."

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.


There's a difference between ensuring that there's a way to
> communicate (which should be covered here), and ensuring a requirement
> for a specific transport.
>

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.

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