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

Re: possibly additional requirement for web intents

From: Greg Billock <gbillock@google.com>
Date: Thu, 12 Jul 2012 13:53:59 -0700
Message-ID: <CAAxVY9eiS6LNFWciv1Bu44Z7hTJ9tgiSmDT-6W3dEp8NbkC0+w@mail.gmail.com>
To: Josh Soref <jsoref@rim.com>
Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
At this point, I'm not sure how you'd do this kind of thing with web
intents. The feature isn't really aimed at enumeration, but rather at
invocation/delivery.

Having a method to get all available services, however, is an interesting
solution to the problem of "isHandlerRegistered" that could do double-duty
for things like this. I am pretty worried about the privacy implications of
any enumeration API. Such an enumeration API is fertile ground for
extensions, though -- does that address this use case?

The image I have in mind is that there's an web application which wants to
essentially perform the task of the picker -- presenting a list of possible
services to the user. That's doable, but is something we've so far
envisioned remaining the province of the UA (and perhaps extensions), and
not being available to web content unless they want to use explicit intents
to manage such a feature.






On Thu, Jul 12, 2012 at 8:59 AM, Josh Soref <jsoref@rim.com> wrote:

> I think you could have:
> A "start" intent which a task manager could use to let the user pick a
> task to run. Each task could register for "start" and when the user clicks
> a "start something" button, the task manager triggers the start intent and
> the UA lets the user pick a task.
>
> I think task management itself would be better via WebSockets than
> WebIntents.
>
> You could have a task manager intent which offers some WebSocket protocol,
> and if a UA receives whitelist permission from the User for your task
> manager to continue talking to a device, then it could probably do more or
> less seamless setup for future invocations.
>
> UI in general is left to UAs, and the general intent design is 1-1, not
> 1-many. You could make n requests to get access to n "task managers", and a
> UA as a QoI detail could elect to bubble the requests into a multiselect
> dialog.
>
> That certainly won't be the initial UI implementation, although if the UC
> is shown to be compelling, UAs may shift to accomodate that.
>
> In terms of 1-many proposals, richt's proposal is friendlier to this.
>
> At this time, WebIntents is a big enough task, so I think addressing this
> would be future work.
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
>
Received on Thursday, 12 July 2012 20:54:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 July 2012 20:54:28 GMT