Re: Content of URL picked by Intent

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

Received on Thursday, 13 September 2012 18:17:23 UTC