Re: Content of URL picked by Intent

Any other ideas on this? I think the goal of having a common
vocabulary of Javascript object keys for MIME types is one there's
widespread agreement on -- it's nicely extensible and future-proof.
The remaining difficulty is how to handle multiple passed values.
Using array (that is, [ { ... } ]) for this is really appealing. I
want to make sure we are making the right trade-offs, though.

An alternative which is much wordier and less elegant, but builds more
explicitly on simple-type-is-simple is to use the "multiple" keyword.
So for instance

{ multiple: true } --->

{ multiple: true,
  values: [ { 'url': xxx, 'filename': f }, {'url': yyy, 'filename': f } ] }

I think this is less elegant, but any opinions why it might be
preferable? I like the way it layers nicely atop the simple
single-value case without a requirement for an 'instanceof' check.
You'd end up writing code like...

if (data.multiple) ...
instead of if (data instanceof Array) or, if it's always arrays, if
(data.length > 1)

What are your opinions on this?

As an explicit proposal for the dictionary vocabulary, how about the following:

dictionary MIMEIntentType {
  URL? url;
  DOMString? text;
  Blob? blob;
  DOMString? content-type;
  DOMString? filename;
  DOMString? title;
  DOMString? description;
}

The spec is that this is a smooth transition from what's currently
recommended in the wiki page [1]. For text types (text/*, message/*,
multipart/*) the 'text' field is filled in. For binary types
(application/*, audio/*, video/*, image/*) the 'blob' field is used.
In either case, the 'url' field may be used, and is taken as a url
pointing to a resource of the given type. 'content-type' should be
filled in by services when clients request a wildcard MIME type (say
"image/*") to let them know the exact type of returned data.
'filename', 'title', and 'description' are optional metadata fields
which would before have been in "extras".

-Greg

[1] http://www.w3.org/wiki/WebIntents/MIME_Types

On Tue, Sep 11, 2012 at 11:09 PM, Jungkee Song <jungkee.song@samsung.com> wrote:
>> From: Greg Billock [mailto:gbillock@google.com]
>> Sent: Saturday, September 08, 2012 12:23 AM
>>
>> On Fri, Sep 7, 2012 at 1:50 AM, Jungkee Song <jungkee.song@samsung.com>
>> wrote:
>> > Hi Greg,
>> >
>> > I propose we introduce *collection* [1]. FileList object in File API [2]
>> > already shows *collection* is quite handy to deliver and access list of
>> > objects.
>>
>> We already have in the spec that |data| is an arbitrary structured
>> clone, which can be a collection. A perfectly valid solution is to
>> just always have return types be collections, so in response to a pick
>> intent you'd get:
>>
>> [ { "url": "the url", "filename": "filename" } ]
>
> Yes. In the schema level, client and service can have an agreement that they
> will exchange data in collection type always. To make it explicit, we can
> specify the requirement for data exchange type in related documents.
>
>
>> JS already has the right tools to handle data objects like this. In
>> that world, there's no need for "multiple" -- the payload is always
>> potentially multiple. It is a bit error prone in the sense that for
>> one object you have to return "[obj]" instead of just "obj".
>
> I think for the services that essentially assume multiple-object delivery
> (e.g., Pick Contacts/Media Intent), it is even better for developers to
> always expect the result as collection type even for a single object case
> like [obj]; otherwise, developers always have to check the type (like the
> code example below) as Intents are loosely-coupled and being developed
> independently.
>
>
>> One solution would be to allow both:
>>
>> function intentResult(data) {
>>   if (data instanceof Array) {
>>     handleResult(data[0]);
>>     // obviously not fully general, but you get the idea
>>   } else {
>>     handleResult(data);
>>   }
>> }
>>
>> I prefer using existing machinery rather than inventing a new class to
>> solve this problem. I'm pretty sure that having used structured clone,
>> we have enough latitude to solve this problem at the schema level, and
>> not need any new API complexity.
>
> Yes, I agree.
>
>
>> > --Web IDL
>> > [ArrayClass]
>> > interface ObjectList {
>> >   getter Object? item(unsigned long index);
>> >   readonly attribute unsigned long length;
>> > };
>> >
>> > --ECMAScript (Client)
>> > var mimeObjects = getImageDataBlobList(...); // return collection of
>> > MimeTypeIntentData
>> > var intent = new Intent({
>> >     action: "http://intents.w3.org/pick",
>> >     type: "image/png",
>> >     data: objects
>> > });
>> >
>> > navigator.startActivity(intent);
>> >
>> > --WebIDL (Service)
>> > partial interface Intent {
>> >     readonly attribute Object objectList;
>> > };
>> >
>> > --ECMAScript (Service)
>> > window.intent.objectList.item(0);
>> > or
>> > window.intent.objectList[0]
>> >
>> > both are valid syntax.
>> >
>> > This can be used for Pick Media Intent and Pick Contacts Intent to
>> deliver
>> > array of Media objects and array of Contact objects, respectively as
>> well.
>> > i.e., I think it covers generic use cases in delivering list of
>> *objects*.
>> >
>> > [1] http://www.w3.org/TR/domcore/#collections
>> > [2] http://www.w3.org/TR/FileAPI/#dfn-filelist
>> >
>> >
>> > Jungkee
>> >
>> >
>> >> -----Original Message-----
>> >> From: Greg Billock [mailto:gbillock@google.com]
>> >> Sent: Friday, September 07, 2012 2:39 AM
>> >> To: Norifumi Kikkawa
>> >> Cc: Paul Kinlan; public-web-intents@w3.org
>> >> Subject: Re: Content of URL picked by Intent
>> >>
>> >> The previous thinking on formatting intent payloads for MIME is here:
>> >> http://www.w3.org/wiki/WebIntents/MIME_Types
>> >>
>> >> This has two flaws which we need to fix. First is that it relies on
>> >> |extras| which we don't want to do. The second is that we need to
>> >> figure out how to pass multiple data through, for which I think we'll
>> >> use the "multiple: true" key. There are a few options here, but what I
>> >> am advocating for is that data payloads for MIME types are always
>> >> javascript objects, and that there is a consistent namespace of keys
>> >> across all types. Proposal:
>> >>
>> >> dictionary MimeTypeIntentData {
>> >>   URL url;
>> >>   Blob blob;
>> >>   DOMString text;
>> >>   DOMString filename;
>> >>   boolean multiple;
>> >> }
>> >>
>> >> This plan needs some help when multiple is true. The fields could
>> >> become sequence<URL>, sequence<Blob>, etc., but that's distasteful.
>> >> Any better ideas for how to handle that?
>> >>
>> >> We will almost certainly end up with other keys in this schema for
>> >> MIME types (for example, I've suggested using "errorName" and
>> >> "errorMessage" for keys in error objects to parallel the JS Error type
>> >> fields while trying to keep them separate from potential fields in
>> >> non-error payloads). We've talked about passing 'origin' in some
>> >> situations, and it may come to pass that 'origin' ends up being a
>> >> voluntary payload field for some interchange types. You can imagine
>> >> wanting to attach a "Content-Type" field, especially for something
>> >> like {action: "pick", type: "image/*"} where the service can return
>> >> the exact type of the attached image.
>> >>
>> >> Thanks for pushing on this. This is a critical discussion, as we
>> >> recognized early on, and I'm glad that we're far enough on to be
>> >> tackling it directly. :-)
>> >>
>> >> -Greg
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Sep 5, 2012 at 11:25 PM, Norifumi Kikkawa
>> >> <Norifumi.Kikkawa@jp.sony.com> wrote:
>> >> > Hi Paul, Thank you for your comment.
>> >> >
>> >> > Yes, for sharing purpose, the content of URL doesn't matter in many
>> >> cases.
>> >> > I'm thinking of "view" intent, which will enable a service to play
>> its
>> >> > introduced movie on a TV with the local discovery addendum.
>> >> > In different from the image use case, maybe the view intent should
>> pass
>> >> url
>> >> > to the movie rather than its binary file.
>> >> >
>> >> > Assuming the TV can play MP4 but WebM. I'd like to see a user agent
>> >> > filters out incompatible TV from its picker list based on target
>> movie.
>> >> > For example, to play WebM content, the TV above should not be shown
>> even
>> >> > if it supports 'view' action (, or shown with "can't play" message).
>> >> >
>> >> >> Given have just removed extras, the data attribute in the intent
>> object
>> >> will need to carry extra data, so I will share a link to a document
>> that
>> >> describes how the payload should appear exactly for then share intent
>> >> across multiple data types.
>> >> >
>> >> > Yes. With keeping the type attribute as "video/mp4" to simplify user
>> >> > agent's work for filtering pickers, some other way should tell how to
>> >> > specify the content.
>> >> >
>> >> > In the Data Formats section of http://webintents.org/pick, Brob, Data
>> >> > URI and their list are assumed and may be distincted implicitly. Just
>> >> > adding 'referece URI(?)' here without adding any data attribute is
>> >> > minimum option.
>> >> >
>> >> > Anyway, at first, I'd like to know whether such usage of url in web
>> >> > intents is possible or not since I have never seen it.
>> >> >
>> >> > Thanks,
>> >> > Kikkawa
>> >> >
>> >> > On Wed, 5 Sep 2012 19:12:35 +0900
>> >> > Paul Kinlan <paulkinlan@google.com> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> Text/uri-list is for sharing URLs, it doesn't care what the content
>> is
>> >> behind that URL. Think of a button that is in the browser that just
>> says
>> >> share the URL in then address bar.  It could be a page, movie or PDF
>> file.
>> >> >>
>> >> >> To be very explicit abut sharing a movie file your data type would
>> be
>> >> video/mpeg for example.  Then a URL that is passed in would be a
>> pointer
>> >> to a video file.
>> >> >>
>> >> >> Given have just removed extras, the data attribute in the intent
>> object
>> >> will need to carry extra data, so I will share a link to a document
>> that
>> >> describes how the payload should appear exactly for then share intent
>> >> across multiple data types.
>> >> >>
>> >> >> P
>> >> >>
>> >> >> On 5 Sep 2012 01:22, "Norifumi Kikkawa"
>> >> <Norifumi.Kikkawa@jp.sony.com<mailto:Norifumi.Kikkawa@jp.sony.com>>
>> wrote:
>> >> >> Hi all,
>> >> >>
>> >> >> I found that some media related intents actions can handle not only
>> >> >> binary content but also url list. For example,
>> >> >> http://webintents.org/share, http://webintents.org/pick assume the
>> >> >> text/url type.
>> >> >>
>> >> >> Although I believe this is also useful in case of a single big
>> content
>> >> (e.g.
>> >> >> movie), I concern that the "text/url" type seems not enough
>> >> >> to determine the capability/requirement of services. How can the
>> intent
>> >> >> registration tag say "I can provide a url for movie, but for contact
>> >> >> info"? How to pick a movie by url?
>> >> >>
>> >> >> My question is :
>> >> >> 1. Can a URL be used for such porpose in web intents?
>> >> >> 2. Does it make sense to add some mechanism to expose more detail
>> >> >> info in "text/url" case?
>> >> >>
>> >> >> A URL may reveal its origin, but this is another issue...
>> >> >>
>> >> >> Thanks,
>> >> >> Kikkawa
>> >> >>
>> >> >> ---------------------------------------------
>> >> >>  Norifumi Kikkawa
>> >> <Norifumi.Kikkawa@jp.sony.com<mailto:Norifumi.Kikkawa@jp.sony.com>>
>> >> >>   Section 1
>> >> >>   Network Technology Dept.
>> >> >>   Information Technology Development Division
>> >> >>   System & Software Technology Platfotm
>> >> >>   Sony Corporation
>> >> >>  (TEL) +81 50 3750 3953<tel:%2B81%2050%203750%203953>
>> >> >> -----------------------------------------------
>> >> >>
>> >> >>
>> >> >
>> >> > ---------------------------------------------
>> >> >  Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
>> >> >   Section 1
>> >> >   Network Technology Dept.
>> >> >   Information Technology Development Division
>> >> >   System & Software Technology Platfotm
>> >> >   Sony Corporation
>> >> >  (TEL) +81 50 3750 3953
>> >> > -----------------------------------------------
>> >> >
>> >> >
>> >
>

Received on Wednesday, 12 September 2012 17:31:45 UTC