Re: Content of URL picked by Intent

Hi,

A service may pass contents to WebIntents and may get them from
WebIntents. Do you mean whenever it uses / supports WebIntents with
contents, it must be able to receive multiple contents?

As you state, it's OK that a service which is able to send only a single
content. But receiving multiple seems mandatory if there is no way to
tell only one content is expected.

Thanks,
Kikkawa

On Sat, 8 Sep 2012 00:14:50 +0900
Greg Billock <gbillock@google.com> wrote:

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

---------------------------------------------
 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 Monday, 10 September 2012 01:34:54 UTC