Re: Content of URL picked by Intent

On Fri, Sep 7, 2012 at 12:31 AM, Norifumi Kikkawa
<Norifumi.Kikkawa@jp.sony.com> wrote:
> Thank you Greg, I understand either (or both) of url and brob is
> available for intent data payload, and in either case the same
> MIME type can be used. That's fine.
>
> I agree that an intent should be able to convey more than one content.
> I'd like to "pick" several pics at a time for example.
>
> I think for the pick case, there are following requiremts.
>
> #1. How to say "I can provide more than one pics" in registration.
> #2. How to say "more than one pics are also ok" in startActivity.

I think we've made the right choice to resist a more complicated
protocol negotiation so far, and I don't think this use case rises to
the level where additional complexity needs to be introduced. There
should be nothing prohibiting a service that only returns a single
image from servicing an intent that allows multiple images to be
returned, and I don't think the user would be able to understand why
that limitation exists and they can't use the service they want.
Better to address this in the interchange format.

> #3. How to convey more than one pics in IntentSuccessCallback.
>
> For #1 and #2, at first we need to clarify managing multiple content
> is mandatory or not. I feel it's optional. If true #1 and #2 should be
> resoleved.
> I hope the type attribute of an intent object should say such capability
> but I don't find good one. Adding "multiple:true" like attribute into
> the intent object rather than the data in intent object is one option.
>
> For #3, another syntax for data would be considerable that the data may
> hold sequence of MimeTypeIntentData, each of which tells a single content.
> This syntax can allow a single intent to manage both blob and url
> content at a time. Content-Type like attribute for each data seems
> helpful as you state.
>
> Thanks,
> Kikkawa
>
> On Fri, 7 Sep 2012 02:38:48 +0900
> Greg Billock <gbillock@google.com> wrote:
>
>> 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 Friday, 7 September 2012 15:15:18 UTC