RE: Content of URL picked by Intent

> From: Greg Billock [mailto:gbillock@google.com]
> Sent: Thursday, September 13, 2012 2:31 AM
> 
> { 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?

#1. Using |multiple| propery
if (data.multiple) {
    for (var i = 0; i < data.values.length; i++)
        console.log(data.values[i]);
} else {
    console.log(data.values);
}
- A downside is "data.values" is used rather than simple "data".
- When multiple is true, data.values.length should be checked according to
its usage anyway.
- A benefit I can think of is it'd provide some base rule such that other
Intent-based services (with other Intent types) can adopt the same data
structure. (but I think it'd add complexity in a large size convoluted
project)

#2. Using *instanceof*
if (data instanceof Array) {
    for (var i = 0; i < data.length; i++)
        console.log(data[i]);
} else {
    console.log(data);
}
- Likewise, not bad but data.length should be checked anyway in the case of
"multiple: true".

#3. Using [{...}]
for (var i = 0; i < data.length; i++)
    console.log(data[i]);

+1. 

The list of objects is quite straightforward and has good examples: 
- var file = document.forms['uploadData']['fileChooser'].files[0] (FileList
in File API)
- getElementByTagName("title")[0], childNodes[0] (in DOM), etc.



> 
> 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".

I think it covers MIME type good. One thing I'm confusing about dictionary
definition is whether it is better to use nullable type for each field. By
definition in WebIDL, each dictionary member is optional. For instance, in
the case we deal with "text/*", should we omit the |blob| at all or put it
as null? Anyway, I agree with the vocab.


Jungkee


> -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 Thursday, 13 September 2012 10:58:07 UTC