Re: Content of URL picked by Intent

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

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 15:06:05 UTC