Service suggestion

14 views
Skip to first unread message

Sean Eagan

unread,
Sep 28, 2011, 11:05:34 AM9/28/11
to web-i...@googlegroups.com
Problem:

When a given activity starts, the user may not have a handler
installed for it, or they may have some installed, but not any they
see as particularly well suited for the given action. In these
situations the user will benefit from being provided suggestions of
services which best support the given activity. These suggestions
could come from two places:

The picker:

The semantic nature of intent registrations, i.e. <intent> tags,
should make it possible for them to be aggregated by search engines
and/or webapp store providers. This could allow picker providers (UAs
or apps/extension to which they delegate) which have access to such
aggregated intent registration data to suggest services to users when
appropriate. Thus, it will be important for such aggregators to
provide access to picker providers, many of which will not have the
capacity to aggregate such data on their own.

The client:

When a client starts an activity, they likely will have an idea of
which services support the activity, and may even have preferred
services for the activity based on testing they've done, a niche data
type they are passing, or they may want to suggest a service which
they provide which they integrate particularly well with. Thus it
could be useful to allow clients to suggest one or possibly more
services. There would be no requirement from the UA on what to do
with the suggestion, they could completely ignore it, or they could
ask the user if they want to install and/or use the suggestion
depending on whether certain criteria matches such as:

* user has no matching handlers installed
* user has no default matching handler installed
* the suggested service is already installed
* the service is not already installed and is confirmed to match by
checking with an intent registration aggregator

Thanks,
Sean Eagan

Paul Kinlan

unread,
Sep 28, 2011, 12:39:13 PM9/28/11
to web-i...@googlegroups.com
Hi Sean,

Thanks, I kind of like the 2nd idea.  Once of the primary reasons behind the intent tag is to service point 1.

I am working on a lightweight registry for webintents.org so that we can start indexing some of the services and we could use it for other UA's to pull the list from.

P
--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5

James Hawkins

unread,
Sep 28, 2011, 2:02:41 PM9/28/11
to web-i...@googlegroups.com
On Wed, Sep 28, 2011 at 8:05 AM, Sean Eagan <seane...@gmail.com> wrote:
Problem:

When a given activity starts, the user may not have a handler
installed for it, or they may have some installed, but not any they
see as particularly well suited for the given action.  In these
situations the user will benefit from being provided suggestions of
services which best support the given activity.  These suggestions
could come from two places:

The picker:

The semantic nature of intent registrations, i.e. <intent> tags,
should make it possible for them to be aggregated by search engines
and/or webapp store providers.  This could allow picker providers (UAs
or apps/extension to which they delegate) which have access to such
aggregated intent registration data to suggest services to users when
appropriate.  Thus, it will be important for such aggregators to
provide access to picker providers, many of which will not have the
capacity to aggregate such data on their own.


The Chrome team is currently working with the Chrome Webstore to provide aggregation of extensions/apps that handle intents; the Webstore team is also adding the ability to query extensions/apps based on Intent filters.  We plan to have a '+' button that will allow the user to install and launch new extensions/apps easily.  Last I knew, Mozilla also has similar plans.
 
The client:

When a client starts an activity, they likely will have an idea of
which services support the activity, and may even have preferred
services for the activity based on testing they've done, a niche data
type they are passing, or they may want to suggest a service which
they provide which they integrate particularly well with.  Thus it
could be useful to allow clients to suggest one or possibly more
services.  There would be no requirement from the UA on what to do
with the suggestion, they could completely ignore it, or they could
ask the user if they want to install and/or use the suggestion
depending on whether certain criteria matches such as:

* user has no matching handlers installed
* user has no default matching handler installed
* the suggested service is already installed
* the service is not already installed and is confirmed to match by
checking with an intent registration aggregator


I'm concerned about expanding the API footprint for a problem that can be solved by the UA.  What are you imagining the API modification would look like?

James

Sean Eagan

unread,
Sep 28, 2011, 2:57:19 PM9/28/11
to web-i...@googlegroups.com
On Wed, Sep 28, 2011 at 1:02 PM, James Hawkins <jhaw...@chromium.org> wrote:
> On Wed, Sep 28, 2011 at 8:05 AM, Sean Eagan <seane...@gmail.com> wrote:
>>
>> Problem:
>>
>> When a given activity starts, the user may not have a handler
>> installed for it, or they may have some installed, but not any they
>> see as particularly well suited for the given action.  In these
>> situations the user will benefit from being provided suggestions of
>> services which best support the given activity.  These suggestions
>> could come from two places:
>>
>> The picker:
>>
>> The semantic nature of intent registrations, i.e. <intent> tags,
>> should make it possible for them to be aggregated by search engines
>> and/or webapp store providers.  This could allow picker providers (UAs
>> or apps/extension to which they delegate) which have access to such
>> aggregated intent registration data to suggest services to users when
>> appropriate.  Thus, it will be important for such aggregators to
>> provide access to picker providers, many of which will not have the
>> capacity to aggregate such data on their own.
>>
>
> The Chrome team is currently working with the Chrome Webstore to provide
> aggregation of extensions/apps that handle intents; the Webstore team is
> also adding the ability to query extensions/apps based on Intent filters.
>  We plan to have a '+' button that will allow the user to install and launch
> new extensions/apps easily.  Last I knew, Mozilla also has similar plans.

I just think it will be important for someone (likely a search engine
provider or webapp store provider) to provide an API for querying for
intent registrations which match a given activity, since many browser
vendors will not be able to implement such a thing on their own.

>
>>
>> The client:
>>
>> When a client starts an activity, they likely will have an idea of
>> which services support the activity, and may even have preferred
>> services for the activity based on testing they've done, a niche data
>> type they are passing, or they may want to suggest a service which
>> they provide which they integrate particularly well with.  Thus it
>> could be useful to allow clients to suggest one or possibly more
>> services.  There would be no requirement from the UA on what to do
>> with the suggestion, they could completely ignore it, or they could
>> ask the user if they want to install and/or use the suggestion
>> depending on whether certain criteria matches such as:
>>
>> * user has no matching handlers installed
>> * user has no default matching handler installed
>> * the suggested service is already installed
>> * the service is not already installed and is confirmed to match by
>> checking with an intent registration aggregator
>>
>
> I'm concerned about expanding the API footprint for a problem that can be
> solved by the UA.

The UA may not be able to handle all situations. For example if it is
offline it will not be able to lookup matching services to suggest.
Also, whatever source from which the UA is pulling intent
registrations to suggest may not yet know about any services which
match, while the client may.

> What are you imagining the API modification would look
> like?

Likely just a property on the client intent instance possibly called
"hint" or "serviceHint" which could either be a string or an array
which does not get forwarded to the service intent instance as with
any other property the client would add. It would be non-normative in
the spec since it is merely a suggestion to the UA, but having it in
the spec at least standardizes a way for the client to suggest
services.

> James
>

Thanks,
Sean Eagan

Sean Eagan

unread,
Sep 28, 2011, 4:46:57 PM9/28/11
to web-i...@googlegroups.com
On Wed, Sep 28, 2011 at 11:39 AM, Paul Kinlan <paulk...@google.com> wrote:
> I am working on a lightweight registry for webintents.org so that we can
> start indexing some of the services and we could use it for other UA's to
> pull the list from.

Great to hear! Manual registration of <intent>-containing URLs would
be a great start, followed by crawling the entire web whenever it
makes sense.

The API would just need to take an action (e.g.
http://webintent.org/share), and an optional type (e.g. image/png) and
return a list of matching service URLs (and dispositions if those
continue to be supported).

Thanks,
Sean Eagan

Paul Kinlan

unread,
Sep 28, 2011, 4:56:13 PM9/28/11
to web-i...@googlegroups.com
That is what I am planning - as for crawling the entire web, the current plan is just to manage this under webintents.org so anything more than crawling submitted sites is out of scope at this time :)

P

Sean Eagan

unread,
Sep 28, 2011, 5:28:48 PM9/28/11
to web-i...@googlegroups.com
Just realized that the "discover" intent is intended for querying
intent registrations. I don't think there would be any reason to open
a browsing context for this, so I'm not sure "discover" makes sense as
an intent unless support is added for a "remote" disposition or
something, where the service receives intents via HTTP headers as
someone previously suggested on public-webapps.

--
Sean Eagan

James Hawkins

unread,
Oct 3, 2011, 4:25:36 PM10/3/11
to web-i...@googlegroups.com
I agree; I've never particularly been a fan of the 'discover' intent.  To speak for Paul, though, the primary use case is for developers to initiate this intent on services in order to see a list of intents they handle.  I think a global intent registry would serve this purpose much better.
Reply all
Reply to author
Forward
0 new messages