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, 6 September 2012 17:39:16 UTC