A few WI spec questions

10 views
Skip to first unread message

Will Meyer

unread,
Sep 9, 2011, 2:29:01 PM9/9/11
to web-i...@googlegroups.com
Hi all,

Great to see the recent developments on WI! Awesome stuff, from a
practitioner's point of view.

I spent a bit of time trying to make a WI proxy for any service that
accepts shares via OExchange (meaning they have a compliant endpoint
URL and an XRD on their host that points to this endpoint [1]), and
have a few questions on the WI spec. Any thoughts appreciated! (BTW
the hosted version of the lib that's handed out in the docs is
http://webintents.org/webtintents.min.js, which 404s — examples. host
is fine).

* Is the model essentially that all interactions are within a popup,
and if so what is the size? Curious for both the within-iframe as
well as new-window cases. There is a mention of disposition inline
but I've not seen other dispositions, nor a ton of docs on the
providers/intent-handlers/services side of the api other than whats in
the JS. Is the UX offered by the example JS the latest prescription
for the UX from the UA's point of view?

* I'd like to register a prompt/verb along with my intent; can I do
that somehow? IOW, if I'm twitter I want my "share" verb to be
"tweet", if I'm StumbleUpon I want it to be "Stumble this", etc. I
want that branding to show up in the UA's picker menus. I'm not clear
how to do this with the intent tag — are other attributes planned?
(similar Q for additional logos/icons, locale options).

* Can I have multiple intent providers for the same type on the same
domain but named differently? It appears keyed off of host from what
I can tell.

* The reference JS doesn't have any UI for accepting/declining intent
providers when they are encountered for the first time — is that the
intent in terms of UA behavior or just a state of the current JS?

* What is the relationship thought to be between the WI verbs[8] and
Activity Streams[7]? e.g. will a "like" be a WI "share"? The AS verb
set has some gaps to be sure, but is the intent that the WI verbs will
be in parallel with or a super(or sub)set of AS?

* On intent registration, type is listed as optional. What is the
default — is it defined indirectly by the action/intent in use?

* <Bikeshedding> the intent/action/verb/service language is a bit
confusing on first glance — registering yourself as being able to
satisfy a user's intent to perform an action by yourself declaring an
"intent", for example.

* Is there any plan to have a set of events along with the

* Is there a set of events defined as part of the spec, informally or
formally at this point?

There are about 350 services [9] that I can bootstrap into WI interop
if I can figure a few of these things out.

Also, more generally, can you point me to anything that summarizes the
general status of the various works? I'm not compeltely clear where
introducer/websend work stands, whether the app-manifest ideas mozilla
has talked about and implemented in its demo extensions [2, 3, 4] are
being considered as an alternative to using the intent tag for
discovery, as well as whether the very latest version of the spec is
whats up publicly up [5, 6].

Gracias,

W

1: http://www.oexchange.org/guide/
2: https://developer.mozilla.org/en/OpenWebApps/The_Manifest
3: http://www.open-mike.org/entry/using-web-applications-for-service-discovery
4: https://github.com/mozilla/openwebapps/blob/master/docs/MANIFEST.md
5: https://github.com/PaulKinlan/webintents
6: http://webintents.org/
7: http://activitystrea.ms/head/activity-schema.html#verbs
8: http://webintents.org/#defaultintents
9: http://www.addthis.com/services

Paul Kinlan

unread,
Sep 9, 2011, 5:20:46 PM9/9/11
to web-i...@googlegroups.com
Hi Will,

Thanks for the email, there is a lot to address so I will try and clear some of the points up inline..

Paul.

On Fri, Sep 9, 2011 at 11:29 AM, Will Meyer <wi...@willmeyer.com> wrote:
Hi all,

Great to see the recent developments on WI!  Awesome stuff, from a
practitioner's point of view.

I spent a bit of time trying to make a WI proxy for any service that
accepts shares via OExchange (meaning they have a compliant endpoint
URL and an XRD on their host that points to this endpoint [1]), and
have a few questions on the WI spec.  Any thoughts appreciated!  (BTW
the hosted version of the lib that's handed out in the docs is
http://webintents.org/webtintents.min.js, which 404s — examples. host
is fine).

The is a type in that url, it looks like there is an error in the docs.  Will fix now and push changes.
 

* Is the model essentially that all interactions are within a popup,
and if so what is the size?  Curious for both the within-iframe as
well as new-window cases.  There is a mention of disposition inline
but I've not seen other dispositions, nor a ton of docs on the
providers/intent-handlers/services side of the api other than whats in
the JS.  Is the UX offered by the example JS the latest prescription
for the UX from the UA's point of view?

It is not the intention that all interactions are within a popup.  The service application can define the disposition  we are still working on defining the correct syntax but a value of "inline" will indicate that the application should be hosted inside the intent picker.  By default applications will open in a new window - the naming of such might be "window".

The current JS shim is very much an experimentation ground, you will notice for instance that the "Share URL" example opens up links inline, but the "Share Image" example opens up the application in a new window.

Dispostition is still very early on in the design cycle and as such I haven't pushed documentation other than what is described in the issue on github.


* I'd like to register a prompt/verb along with my intent; can I do
that somehow?  IOW, if I'm twitter I want my "share" verb to be
"tweet", if I'm StumbleUpon I want it to be "Stumble this", etc.  I
want that branding to show up in the UA's picker menus.  I'm not clear
how to do this with the intent tag — are other attributes planned?
(similar Q for additional logos/icons, locale options).

The current design is for the "title" in the intent tag to be what is displayed in the Picker.  If no title is specified we are currently defaulting to the document.title.  Likewise for Logo's, applications can provide their own logo or the UA will choose the favicon.

Locale options is a good point and is currently not addressed in the UA.  The initial assumption would be that the application would present the title it wanted to display to the user based on how it detected the users language and regional settings, for example Twitter might detect the user is currently in Spanish and thus register the intent with a Spanish title.
 

* Can I have multiple intent providers for the same type on the same
domain but named differently?  It appears keyed off of host from what
I can tell.

Yes you can.  The current shim is actually keyed off intent so webintents.org/share then it is keyed of "href" of the app that will be launched and then it is further keyed of data type, so you can't have one page handle "share" twice for the same data type, but you can have one page handle "share" and "edit" or you could have two pages in the same domain both handle "share", or you could have a single page handle "share" for image data and "share" for urls.

I hope I explained that properly.  But in effect the shim will add a new intent to the system if the following criteria is not met: "if(intent.action == action.action && intent.url == action.url && intent.type == action.type)" - otherwise it will overwrite the existing data.
 

* The reference JS doesn't have any UI for accepting/declining intent
providers when they are encountered for the first time — is that the
intent in terms of UA behavior or just a state of the current JS?

There is an open issue about this, it needs to be fixed. https://github.com/PaulKinlan/WebIntents/issues/48, I believe we are prescribing that this should be an option for the UA to manage.
 

* What is the relationship thought to be between the WI verbs[8] and
Activity Streams[7]?  e.g. will a "like" be a WI "share"?  The AS verb
set has some gaps to be sure, but is the intent that the WI verbs will
be in parallel with or a super(or sub)set of AS?

The reason we are using URI's is so that we can handle things such as Activity Stream verbs, as long as the URI to identify the verb is a valid URI - my initial thoughts around this earlier in the year were based on my understanding of the XML version of the activity stream spec which defined the verb as http://activitystrea.ms/schema/1.0/verb (http://activitystrea.ms/schema/1.0/post for example).

Likewise, the data that you pass through to the applications that handle the users intent can specify the format as an activity stream encoded piece of data as long as the filter is provided as a MIME type - so activitystream/photo when used in the "startActivity" would only list services that supported the same data payload.

We are trying not to step on the toes of the already pre-defined verbs on activity streams, but at the same time we are not mapping likes to shares, it is soley handled by matching the URI of "intent" provided by the service against that of what the calling application wishes to initiate.

* On intent registration, type is listed as optional.  What is the
default — is it defined indirectly by the action/intent in use?

The service defines the data types it can handle in the intent registration, "*" for any, or image/* for example handle any image, or it can be very specific image/png.

The type filtering on invocation by the client are string matched mime types. The client will say, I am sending an image/png or of they don't know it might be image/* or even worse *.  The User agent will then resolve a list of all the services the can handle that data type.  If the client passes *, then a list of all services that can handle the users intent are listed.


* <Bikeshedding> the intent/action/verb/service language is a bit
confusing on first glance — registering yourself as being able to
satisfy a user's intent to perform an action by yourself declaring an
"intent", for example.

I will clear some of that up. :)
 

* Is there any plan to have a set of events along with the

What is after "the"...?  Are you thinking about events on the intent tag?  Success or failure of registration etc?
 

* Is there a set of events defined as part of the spec, informally or
formally at this point?

No.  Data is returned from the calling application and it invokes a developer defined callback.  The application that is opened by the user, the handler of the intent, just inspects window.intent to get the data, there are no "onintent" events that you as a service application need to handle, you just read the data at "onload" or where ever you need it.

Likewise the client application will be notified via a callback when a response has been posted by the service.

Do you have any examples of events that you believe we must have?
 

There are about 350 services [9] that I can bootstrap into WI interop
if I can figure a few of these things out.

I actually wanted to come and speak to you!  I will email you off the list.
 
Also, more generally, can you point me to anything that summarizes the
general status of the various works?  I'm not compeltely clear where
introducer/websend work stands, whether the app-manifest ideas mozilla
has talked about and implemented in its demo extensions [2, 3, 4] are
being considered as an alternative to using the intent tag for
discovery, as well as whether the very latest version of the spec is
whats up publicly up [5, 6].

Our current efforts are around building the Web Intents work into Chrome so that there is not a need for the shim.  There have been commits recently in to the Chromium tree. We are not working on Introducer.

We believe the intent tag is the most appropriate way for us to understand that apps have the intention of handling an intent, both from a UA model of discovering capabilities and prompting the user to install them with out the burden of extra requests to the service, and also from a boot strapping point of view, it is possible for UA vendors to build an engine that will be able to recommend applications to the user in the case when a user might not have a relevant app installed.

We don't want to get in to a situation like we did with AppCache where the developer experience is so poor that most people don't implement it.  This makes it very hard to justify managing extra files on the server.  The best situation we can be in is that developers can copy an example into their app and instantly start being an intent service. 

The intent tag offers the flexibility to both UA's, Developers and Users (through bootstrapping and responsiveness).

The thing to note about the manifest is that it assumes at somepoint that it is an app or something that is installed and this we believe will not always be the case and we don't want to force membership in any particular store to be able to use intents.



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

Will Meyer

unread,
Sep 11, 2011, 6:59:07 PM9/11/11
to web-i...@googlegroups.com
Cool, thanks Paul. Inline...

>> * Is the model essentially that all interactions are within a popup,
>> and if so what is the size?  Curious for both the within-iframe as
>> well as new-window cases.  There is a mention of disposition inline
>> but I've not seen other dispositions, nor a ton of docs on the
>> providers/intent-handlers/services side of the api other than whats in
>> the JS.  Is the UX offered by the example JS the latest prescription
>> for the UX from the UA's point of view?
>
> It is not the intention that all interactions are within a popup.  The
> service application can define the disposition  we are still working on
> defining the correct syntax but a value of "inline" will indicate that the
> application should be hosted inside the intent picker.  By default
> applications will open in a new window - the naming of such might be
> "window".
> The current JS shim is very much an experimentation ground, you will notice
> for instance that the "Share URL" example opens up links inline, but the
> "Share Image" example opens up the application in a new window.
> Dispostition is still very early on in the design cycle and as such I
> haven't pushed documentation other than what is described in the issue on
> github.
>>

Gotcha. Assume this list is the place to keep up to date/participate
in the discussions on that design? I'll change my proxy BTW to use
the mechanism of the image example.

>> * I'd like to register a prompt/verb along with my intent; can I do
>> that somehow?  IOW, if I'm twitter I want my "share" verb to be
>> "tweet", if I'm StumbleUpon I want it to be "Stumble this", etc.  I
>> want that branding to show up in the UA's picker menus.  I'm not clear
>> how to do this with the intent tag — are other attributes planned?
>> (similar Q for additional logos/icons, locale options).
>
> The current design is for the "title" in the intent tag to be what is
> displayed in the Picker.  If no title is specified we are currently
> defaulting to the document.title.  Likewise for Logo's, applications can
> provide their own logo or the UA will choose the favicon.
> Locale options is a good point and is currently not addressed in the UA.
>  The initial assumption would be that the application would present the
> title it wanted to display to the user based on how it detected the users
> language and regional settings, for example Twitter might detect the user is
> currently in Spanish and thus register the intent with a Spanish title.
>

In my view there's a difference between the name of the service as
would be seen in something like a management interface, preferences
picker, etc, and the call to action that makes sens at time of intent.
I'd suggest the design support both notions. (For all of this,
including the localization behavior you suggest, I assume the model is
that the intent handler registration overrides previous instances and
thus can be updated on every view of a page that includes it
(conceptually, certainly there could be implementation techniques to
do it more efficiently)).

>>
>> * Can I have multiple intent providers for the same type on the same
>> domain but named differently?  It appears keyed off of host from what
>> I can tell.
>
> Yes you can.  The current shim is actually keyed off intent so
> webintents.org/share then it is keyed of "href" of the app that will be
> launched and then it is further keyed of data type, so you can't have one
> page handle "share" twice for the same data type, but you can have one page
> handle "share" and "edit" or you could have two pages in the same domain
> both handle "share", or you could have a single page handle "share" for
> image data and "share" for urls.
> I hope I explained that properly.  But in effect the shim will add a new
> intent to the system if the following criteria is not met: "if(intent.action
> == action.action && intent.url == action.url && intent.type == action.type)"
> - otherwise it will overwrite the existing data.

Got it.

>> * What is the relationship thought to be between the WI verbs[8] and
>> Activity Streams[7]?  e.g. will a "like" be a WI "share"?  The AS verb
>> set has some gaps to be sure, but is the intent that the WI verbs will
>> be in parallel with or a super(or sub)set of AS?
>
> The reason we are using URI's is so that we can handle things such
> as Activity Stream verbs, as long as the URI to identify the verb is a valid
> URI - my initial thoughts around this earlier in the year were based on my
> understanding of the XML version of the activity stream spec which defined
> the verb as
> http://activitystrea.ms/schema/1.0/verb (http://activitystrea.ms/schema/1.0/post
> for example).
> Likewise, the data that you pass through to the applications that handle the
> users intent can specify the format as an activity stream encoded piece of
> data as long as the filter is provided as a MIME type - so
> activitystream/photo when used in the "startActivity" would only list
> services that supported the same data payload.
> We are trying not to step on the toes of the already pre-defined verbs on
> activity streams, but at the same time we are not mapping likes to shares,
> it is soley handled by matching the URI of "intent" provided by the service
> against that of what the calling application wishes to initiate.
>>

I'm mostly following -- I think for this to be most useful as a
general concept there has to be fairly strong definition around the
intents and what they mean conceptually, so that there's a greater
chance services will implement things that both make sense for the
use-cases the publisher has in mind (that they implement support for
without knowing which providers the user will be presented with), but
also don't become so specialized as to reduce the options a user gets
in practical use. We took a different approach with OExchange, which
was to require a URI of content in ALL cases, and not define mandatory
type handling (optional is fine). For example, a key use case is the
photo site use case, where as the page developer I just want the user
to be able to share my photo, regardless of whether the service the
user wants to use to share it accepts rich photo data or just urls to
pages, without knowing its a photo page. For "sharing" specifically,
the power of a spec like WI will be realized not when twitter FB and a
few other services can be shared to, but when a huge number of
reasonable options can be auto-selected down to a set that is
preferred by an individual user. All of that is to say that I would
advocate for strong definition around the most basic and probably most
widely-used -- "sharing" -- such that as a page developer it is
possible to accomplish that most basic action without having to
provide many different activities to handle all of the different ways
a service could "accept" a photo.

>> * On intent registration, type is listed as optional.  What is the
>> default — is it defined indirectly by the action/intent in use?
>
> The service defines the data types it can handle in the intent registration,
> "*" for any, or image/* for example handle any image, or it can be very
> specific image/png.
> The type filtering on invocation by the client are string matched mime
> types. The client will say, I am sending an image/png or of they don't know
> it might be image/* or even worse *.  The User agent will then resolve a
> list of all the services the can handle that data type.  If the client
> passes *, then a list of all services that can handle the users intent are
> listed.

Sorry, so I can start an intent with a type of *? What do I pass as
the data, and how does the service know what it is?

>> * Is there any plan to have a set of events along with the
>
> What is after "the"...?  Are you thinking about events on the intent tag?
>  Success or failure of registration etc?
>
>>
>> * Is there a set of events defined as part of the spec, informally or
>> formally at this point?
>
> No.  Data is returned from the calling application and it invokes a
> developer defined callback.  The application that is opened by the user, the
> handler of the intent, just inspects window.intent to get the data, there
> are no "onintent" events that you as a service application need to handle,
> you just read the data at "onload" or where ever you need it.
> Likewise the client application will be notified via a callback when a
> response has been posted by the service.
> Do you have any examples of events that you believe we must have?
>

The use-case I've in mind is on the client side...that I want to track
what users do with my content. So I want to know that the user saw my
image and used service X to edit it. The data passed to onActivity is
the data from the service as far as I understand, which doesn't
include for example the actual service identifying uri. Can I
implement the equivalent of FB.Event.subscribe('edge.create',
function(href, widget) {})?

>>
>> There are about 350 services [9] that I can bootstrap into WI interop
>> if I can figure a few of these things out.
>
> I actually wanted to come and speak to you!  I will email you off the list.
>

Hit me.

Also, I'd love to chat with you re the UA implementation thoughts.
The concept of using a user's activity to try to dynamically whittle
down the list of compatible providers to show them is something we've
been doing in AddThis for a while (we have the notion of "preferred"
services, which is based on a combination of a lot of things,
including user activity), so anxious to hear more about the thinking
on how Chrome would/will do it. Also, FWIW, I had seen mention
somewhere of the idea of hijacking in an extension existing buttons to
replace them with intents -- def have some thoughts on that as it
relates to site-owner perception/desires.

Thanks again for the thorough replies, exciting stuff.

W

Paul Kinlan

unread,
Sep 11, 2011, 10:28:45 PM9/11/11
to web-i...@googlegroups.com
Hey Will,  Not a problem, replies inline ... :) (wave used to be good for this type of thing) :)

We wanted the UA to present the same name to the user across the board so they would be familiar with it when they saw it. The shim at the moment silently updates the configuration as long as the criteria (in the previous mail) match, and I would expect the UA's to do the same.
 
>>
>> * Can I have multiple intent providers for the same type on the same
>> domain but named differently?  It appears keyed off of host from what
>> I can tell.
>
> Yes you can.  The current shim is actually keyed off intent so
> webintents.org/share then it is keyed of "href" of the app that will be
> launched and then it is further keyed of data type, so you can't have one
> page handle "share" twice for the same data type, but you can have one page
> handle "share" and "edit" or you could have two pages in the same domain
> both handle "share", or you could have a single page handle "share" for
> image data and "share" for urls.
> I hope I explained that properly.  But in effect the shim will add a new
> intent to the system if the following criteria is not met: "if(intent.action
> == action.action && intent.url == action.url && intent.type == action.type)"
> - otherwise it will overwrite the existing data.

Got it.

I will make it clear in the FAQ and the documents too.
This is one of the areas where I need to define the process a little more clearly, and where I need to also potentially define how closely we can work with activity streams.  For sharing a URL I expect every to use the mime type text/uri-list.  However sometimes we might want to express the share more verbosely.

If we get to a situation where we say the type is activitystream/*, activitystream/photo

At the same time, I think the widgets are still going to be a huge player, if you can build a widget that can detect the intention of the share, be it image, url, text or a rich snippet.  Services also will play a big part, I expect if a service receives a URI and the type is text/uri-list that it would scrape the page and offer a richer share to the user.

My thoughts are moving to rather than specifying the type and data separately at startActivity, you provide a type keyed object of the data types that you can send through (with attached data).  For instance: { "text/uri-list": "url of the page", "image/png": "http://test.com/kitten1.png", "activitystream/photo": { rich object}}.  The resolution picker then can present all the services that can handle either.

I am still a stickler for the client to determine the best single type it would share; sites and blogs then just the URL, flicker.com the image url etc.
 

>> * On intent registration, type is listed as optional.  What is the
>> default — is it defined indirectly by the action/intent in use?
>
> The service defines the data types it can handle in the intent registration,
> "*" for any, or image/* for example handle any image, or it can be very
> specific image/png.
> The type filtering on invocation by the client are string matched mime
> types. The client will say, I am sending an image/png or of they don't know
> it might be image/* or even worse *.  The User agent will then resolve a
> list of all the services the can handle that data type.  If the client
> passes *, then a list of all services that can handle the users intent are
> listed.

Sorry, so I can start an intent with a type of *?  What do I pass as
the data, and how does the service know what it is?

You can, the service will assume it is something, but not what know what it is.

Hmmm, it makes more sense that the service can define it handles "*", but the client that starts the Activity has to define the exact data it is sending so the service can handle it correctly.

Thinking this further, even if the client says I am sending you an image "image/*", me as a service would want to know what type it is prior to interacting with it.  Content sniffing via the UA or Service will bring on a whole heap of pain for developers.
 

>> * Is there any plan to have a set of events along with the
>
> What is after "the"...?  Are you thinking about events on the intent tag?
>  Success or failure of registration etc?
>
>>
>> * Is there a set of events defined as part of the spec, informally or
>> formally at this point?
>
> No.  Data is returned from the calling application and it invokes a
> developer defined callback.  The application that is opened by the user, the
> handler of the intent, just inspects window.intent to get the data, there
> are no "onintent" events that you as a service application need to handle,
> you just read the data at "onload" or where ever you need it.
> Likewise the client application will be notified via a callback when a
> response has been posted by the service.
> Do you have any examples of events that you believe we must have?
>

The use-case I've in mind is on the client side...that I want to track
what users do with my content.  So I want to know that the user saw my
image and used service X to edit it.  The data passed to onActivity is
the data from the service as far as I understand, which doesn't
include for example the actual service identifying uri.  Can I
implement the equivalent of FB.Event.subscribe('edge.create',
function(href, widget) {})?

We want to try and keep identification of the provided service away from the client if possible but it is up to the service to define what it sends back, if it chooses to identify itself then it is up to that.  If you were twitter, if a user shared publicly you might return the URL of the share, if it was a DM you might choose to return nothing, twitter.com or something else.  The client will still know that a service successfully completed.

Every service should at least return postResult to let you know the action is completed.  The current shim allows you to not return any data, but running with the usecases, a definite completion of the intent should be signaled.

The burden of the what is shared should be on the service that is being interacted with.  The service should at least say the action was successful or not.  Note: there might be a postException.

http://widgets.webintents.org/share.html is supposed to highlight something similar, I want to let the user know that they have already shared this URL, without the ability to determine if an action completed successfully then we couldn't build these services and we couldn't offer analytics to the site owners.
 

>>
>> There are about 350 services [9] that I can bootstrap into WI interop
>> if I can figure a few of these things out.
>
> I actually wanted to come and speak to you!  I will email you off the list.
>

Hit me.

Also, I'd love to chat with you re the UA implementation thoughts.
The concept of using a user's activity to try to dynamically whittle
down the list of compatible providers to show them is something we've
been doing in AddThis for a while (we have the notion of "preferred"
services, which is based on a combination of a lot of things,
including user activity), so anxious to hear more about the thinking
on how Chrome would/will do it.  Also, FWIW, I had seen mention
somewhere of the idea of hijacking in an extension existing buttons to
replace them with intents -- def have some thoughts on that as it
relates to site-owner perception/desires.

We are working on the exact presentation to the user of the services, the current thinking is based off metrics such as usage of the service - if a user always shares via AddThis, then that should be the first choice.  This whole process is being left the UA.

Regarding extensions, it is something that I am working on now.  If you look at the tools directory, there is a generic "share" action that simply fires the picker.  I am wrestling with some window.name issues for the shim at the moment but I would love to see the browser integration of intents starting with extensions.
 

Thanks again for the thorough replies, exciting stuff.

W

Thanks for all the feedback!

P

Will Meyer

unread,
Sep 13, 2011, 4:40:24 PM9/13/11
to web-i...@googlegroups.com

That makes sense as a goal, but I still think it should be possible
for the service (what are they "formally" called in WI by the way --
the things that handle intents?) to provide more custom user
experiences to users than just a generic name of the service. For the
sharing case, at least, a lot of the sharing buttons are not really
just sharing buttons, they are extensions of that services' experience
into the page (e.g. Will and 50 of your other friends liked this). To
the extent that services can still accomplish at least a basic level
of this in the context of being an intent provider, I think you'd see
increased support from the services.

Agree that it would be better to be able to offer multiple types than
to require separate initiations for each type. And yes, widgets can
help here. A photo site should be able to specify that it would like
to allow a user to share this image, and provide a basic url to the
image page, and the actual image data, and depending on which services
the user uses, they would get more or less rich options ("Open in
Aperture", "Tweet this image")

> >> * On intent registration, type is listed as optional.  What is the
>> >> default — is it defined indirectly by the action/intent in use?
>> >
>> > The service defines the data types it can handle in the intent
>> > registration,
>> > "*" for any, or image/* for example handle any image, or it can be very
>> > specific image/png.
>> > The type filtering on invocation by the client are string matched mime
>> > types. The client will say, I am sending an image/png or of they don't
>> > know
>> > it might be image/* or even worse *.  The User agent will then resolve a
>> > list of all the services the can handle that data type.  If the client
>> > passes *, then a list of all services that can handle the users intent
>> > are
>> > listed.
>>
>> Sorry, so I can start an intent with a type of *?  What do I pass as
>> the data, and how does the service know what it is?
>
> You can, the service will assume it is something, but not what know what it
> is.
> Hmmm, it makes more sense that the service can define it handles "*", but
> the client that starts the Activity has to define the exact data it is
> sending so the service can handle it correctly.

yes exactly.

> Thinking this further, even if the client says I am sending you an image
> "image/*", me as a service would want to know what type it is prior to
> interacting with it.  Content sniffing via the UA or Service will bring on a
> whole heap of pain for developers.

Also agree, the service should be able to declare support for multiple
types for the purposes of registration and user preference management,
but when it comes to an individual interaction, it should be "strongly
typed".

I agree it should not be possible necessarily for sites to sniff for
user preferred services as managed by the ua, but I think the
analytics use-case is vitally important. All current "buttons" that
drive real value for site owners support this in some way -- facebook,
twitter, etc. AddThis supports it for rolled-up services as well. If
the model is that there would be widgets, in reality, doing this kind
of thing, then yes they can do the tracking themselves as they are in
the flow (and this is what they do today).

Additionally, it seems odd to define the input to the service but not
the output. The contract should be defined in both ways -- this may
be an area where I'm missing some docs (the link to the "spec" on the
site just goes to the same home page and I couldn't find a detail of
this reverse interaction). If its not defined then as an initiator of
intents I will never inspect it.

>> Also, I'd love to chat with you re the UA implementation thoughts.
>> The concept of using a user's activity to try to dynamically whittle
>> down the list of compatible providers to show them is something we've
>> been doing in AddThis for a while (we have the notion of "preferred"
>> services, which is based on a combination of a lot of things,
>> including user activity), so anxious to hear more about the thinking
>> on how Chrome would/will do it.  Also, FWIW, I had seen mention
>> somewhere of the idea of hijacking in an extension existing buttons to
>> replace them with intents -- def have some thoughts on that as it
>> relates to site-owner perception/desires.
>
> We are working on the exact presentation to the user of the services, the
> current thinking is based off metrics such as usage of the service - if a
> user always shares via AddThis, then that should be the first choice.  This
> whole process is being left the UA.

To the extent those UA discussions could be bubbled up to this list,
that would be great -- this will either work or not work, ultimately,
depending on that.

James Hawkins

unread,
Sep 13, 2011, 4:47:10 PM9/13/11
to web-i...@googlegroups.com
Will,

Please see http://dev.chromium.org/developers/design-documents/webintentsapi for the latest draft of the API.

To answer one of your questions, the draft defines services as services, which is short for Service Provider (service, provider, service provider, handler, etc. are all understood to be the service in client/service).

Thanks,
James
Reply all
Reply to author
Forward
0 new messages