Re: Content of URL picked by Intent

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.
#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 07:32:10 UTC