Re: Content of URL picked by Intent

I don't like using "multiple" as a field on the intent object. It
doesn't always make sense, and seems like something that ought to be
treated at the interchange data format layer.

The more I consider this, the more I like using the 'type' parameter
to communicate this. So something like "[]image/*" or "[image/*]" or
"multipart/mixed;type=image/*" to indicate that the service can
provide multiple object support, or that client is expecting it.
That's nicely explicit, builds on the single-value case, and will work
for all the use cases we know of.

>From a purely technical standpoint, I think using multipart/... is
correct. Is it too unwieldy though?



On Wed, Sep 19, 2012 at 2:11 AM, Norifumi Kikkawa
<Norifumi.Kikkawa@jp.sony.com> wrote:
> Hi,
>
>> > It sounds like we are saying here that a 'profile' may require an array where it makes sense (e.g. Pick Contacts) and otherwise it can be either an array or single, requiring checking; though it might be simpler to always require returning an array.
>
> A more explicit way (like specifying "multiple") is sometimes useful in
> a Pick-Media type use case even if an array is available for intent.
>
> Note that my point here is multiple contents in the post result data
> retruned in the IntentSuccessCallback and NOT multiple contents
> in data of Intent object.
>
> Please assume a service just wants a single image to edit. If it can
> tell "just one image is enough" at the startActivity time, the invoked
> service which supports "Pick-Media" web intents can arrange its intent
> page for a user to select only a single image - disabling multiple
> selection for example.
>
> I believe this is not a Pick-Media specific requirement. Therefore the
> WebIntents spec should have a way for a service to allow/prohibit
> multiple post result contents like below;
>
> interface Intent {
>     readonly attribute DOMString     action;
>     readonly attribute DOMString     type;
>     readonly attribute any           data;
>     readpnly attribute Boolean    multiplePostResults;
>         // true if multiple result is allowed.
>     readonly attribute MessagePort[] ports;
>     void postResult (any data, optional sequence<Transferable> transferable);
>     void postFailure (any data);
> };
>
> This requirement is not applicable for intent actions which don't use a
> post result.
>
> Don't you think this is useful?
>
> Thanks,
> Kikkawa
>
>
> On Fri, 14 Sep 2012 03:16:55 +0900
> Greg Billock <gbillock@google.com> wrote:
>
>> On Thu, Sep 13, 2012 at 8:04 AM,  <Frederick.Hirsch@nokia.com> wrote:
>> > It sounds like we are saying here that a 'profile' may require an array where it makes sense (e.g. Pick Contacts) and otherwise it can be either an array or single, requiring checking; though it might be simpler to always require returning an array.
>> >
>> > To make sense of information an agreement is needed so we can expect a 'profile' like Pick Contacts etc, to specify that an array is returned, if this is not the mandatory default.
>> >
>> > What is the downside of using a Javascript array? Seems straightforward and simple...
>>
>> No downside -- that's what I prefer. The only thing I worry about is
>> if it is enough of a gotcha for simple cases (single values) that we
>> should do either something more explicit (like "multiple") or also
>> recommend handling a single object as { ... } instead of [ { ... } ].
>> Both are accommodations, and so are disappointing, but if they end up
>> making the API simpler to work with for most cases, I see the case for
>> making them.
>>
>> >
>> > regards, Frederick
>> >
>> > Frederick Hirsch
>> > Nokia
>> >
>> >
>> >
>> > On Sep 12, 2012, at 2:09 AM, ext Jungkee Song 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
>> >>>>>> -----------------------------------------------
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>
>> >>
>> >
>
> ---------------------------------------------
>  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, 19 September 2012 17:39:19 UTC