Re: web intent semantics?

Hi Dave,

CIL

On Tue, Feb 21, 2012 at 12:29 PM, Dave Raggett <dsr@w3.org> wrote:
>
> I am implementing web intents as a chrome extension and would like to
> better understand the semantics of the "share" intent, e.g. for photos.
>
> What is responsible for selecting the photo to share?
>
>   a. the current web page that invokes the share intent
>   b. the user selected photo sharing service
>
> As far as I can tell, the Google proposal is for (b) as I haven't found
> any mention of the API for passing a photo to a photo sharing site.

It is (a) - The current page passes the data to the photo sharing
service in the intent object.

var i = new Intent("http://webintents.org/share", "image/*", .... the
data goes here ...);
navigator.startActivity(i); // starts the intent and sends the data.

I think if you are using the "picker" example, then it would look like
(b) - but that is not the case, we support (a).


>
> The first interpretation (a) would be nice as it would avoid the need
> for the user to re-select the photo in the situation where the current
> web page has already selected it. You could also use one service to
> select one or more photos, and another service to share them with.
>
> The picker example [1] seems to assume that the service returns
> something that is mapped into an array, the zeroth entry of which is the
> URL for the image. I wasn't able to spot where this detail was defined.
> Can you please point me where to look?

http://webintents.org/pick - I need to actually expand that list to
include Blob data as well.

Should the data always be an array?  Or as it is now - maybe an array
or just an object?

>
> The discover intent appears to return a JSON data structure that in some
> as yet undefined way describes the APIs a target site supports. Of
> course, I may be mistaken in my interpretation, as it could perhaps just
> return a URL that dereferences to the JSON data structure. What is the
> correct interpretation?

It could return a URL, but can easily just be a JSON object
(especially if the mime type is "application/javascript") but please
generally disregard the discover intent, it was ill-conceived and
needs a lot more work than what I initially put into it.

Web Intents are be able to work just by passing the physical data
between client and service (all on the user space), so passing the
physical data is key.  This is especially important for offline.

> Are web intent responses limited to URLs?

No, Strings, Blobs, TypedArrays, MessagePorts, technically anything
that can be considered in the structured clone algorithm.

>
>
> [1] http://examples.webintents.org/intents/pick/pick.html
>
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>



--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

Received on Tuesday, 21 February 2012 13:48:33 UTC