- From: Greg Billock <gbillock@google.com>
- Date: Wed, 12 Sep 2012 10:31:16 -0700
- To: Jungkee Song <jungkee.song@samsung.com>
- Cc: Paul Kinlan <paulkinlan@google.com>, public-web-intents@w3.org, public-device-apis@w3.org, Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
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