Re: Content of URL picked by Intent

Hi, thank you for your comments, Greg and Paul.
I like Paul's idea. Consistency with android intent must help developers.

Kikkawa

On Thu, 20 Sep 2012 03:07:05 +0900
Paul Kinlan <paulkinlan@google.com> wrote:

> The other option is following what andoird has done and differentiate at the action level, that is they have send and send_multiple, this then leaves up to each actions specification to say how the data interchange occurs.
> 
> On 19 Sep 2012 18:38, "Greg Billock" <gbillock@google.com<mailto:gbillock@google.com>> wrote:
> I don't like using "multiple" as a field on the intent object. It
> doesn't always make sense, and seems like something that ought to be
> treated at the interchange data format layer.
> 
> The more I consider this, the more I like using the 'type' parameter
> to communicate this. So something like "[]image/*" or "[image/*]" or
> "multipart/mixed;type=image/*" to indicate that the service can
> provide multiple object support, or that client is expecting it.
> That's nicely explicit, builds on the single-value case, and will work
> for all the use cases we know of.
> 
> From a purely technical standpoint, I think using multipart/... is
> correct. Is it too unwieldy though?
> 
> 
> 
> On Wed, Sep 19, 2012 at 2:11 AM, Norifumi Kikkawa
> <Norifumi.Kikkawa@jp.sony.com<mailto:Norifumi.Kikkawa@jp.sony.com>> wrote:
> > Hi,
> >
> >> > 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.
> >
> > A more explicit way (like specifying "multiple") is sometimes useful in
> > a Pick-Media type use case even if an array is available for intent.
> >
> > Note that my point here is multiple contents in the post result data
> > retruned in the IntentSuccessCallback and NOT multiple contents
> > in data of Intent object.
> >
> > Please assume a service just wants a single image to edit. If it can
> > tell "just one image is enough" at the startActivity time, the invoked
> > service which supports "Pick-Media" web intents can arrange its intent
> > page for a user to select only a single image - disabling multiple
> > selection for example.
> >
> > I believe this is not a Pick-Media specific requirement. Therefore the
> > WebIntents spec should have a way for a service to allow/prohibit
> > multiple post result contents like below;
> >
> > interface Intent {
> >     readonly attribute DOMString     action;
> >     readonly attribute DOMString     type;
> >     readonly attribute any           data;
> >     readpnly attribute Boolean    multiplePostResults;
> >         // true if multiple result is allowed.
> >     readonly attribute MessagePort[] ports;
> >     void postResult (any data, optional sequence<Transferable> transferable);
> >     void postFailure (any data);
> > };
> >
> > This requirement is not applicable for intent actions which don't use a
> > post result.
> >
> > Don't you think this is useful?
> >
> > Thanks,
> > Kikkawa
> >
> >
> > On Fri, 14 Sep 2012 03:16:55 +0900
> > Greg Billock <gbillock@google.com<mailto:gbillock@google.com>> wrote:
> >
> >> On Thu, Sep 13, 2012 at 8:04 AM,  <Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>> wrote:
> >> > 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...
> >>
> >> No downside -- that's what I prefer. The only thing I worry about is
> >> if it is enough of a gotcha for simple cases (single values) that we
> >> should do either something more explicit (like "multiple") or also
> >> recommend handling a single object as { ... } instead of [ { ... } ].
> >> Both are accommodations, and so are disappointing, but if they end up
> >> making the API simpler to work with for most cases, I see the case for
> >> making them.
> >>
> >> >
> >> > regards, Frederick
> >> >
> >> > Frederick Hirsch
> >> > Nokia
> >> >
> >> >
> >> >
> >> > On Sep 12, 2012, at 2:09 AM, ext Jungkee Song wrote:
> >> >
> >> >>> From: Greg Billock [mailto:gbillock@google.com<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<mailto: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<mailto:gbillock@google.com>]
> >> >>>>> Sent: Friday, September 07, 2012 2:39 AM
> >> >>>>> To: Norifumi Kikkawa
> >> >>>>> Cc: Paul Kinlan; public-web-intents@w3.org<mailto: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<mailto: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<mailto: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><mailto: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><mailto: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><tel:%2B81%2050%203750%203953>
> >> >>>>>>> -----------------------------------------------
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> ---------------------------------------------
> >> >>>>>> 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<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, 20 September 2012 05:23:16 UTC