W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2012

RE: Pick Media Intent Review

From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Date: Thu, 18 Oct 2012 12:57:44 +0000
To: Jungkee Song <jungkee.song@samsung.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>, "'WebIntents'" <public-web-intents@w3.org>
Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE20B6FF@ADELE.crf.canon.fr>
Hi Jungkee,

Thanks for pinging me.

>From a client side perspective, it kind of makes sense to split between single-mime and several-media pickers,
at least as long as providers are supporting the two picker flavors.
The situation would look bad though if Flickr and Picasa were not supporting at least one common picker.
Probably the picker definitions should be aligned as much as possible, especially the data in and out parameters.
By the way, is there any ongoing activity to define mime media picker?

I also tested the demo, which looks good.
I tried for fun to modify the provider page so that it supports both video/* and media pickers within the same page.
As you can see from the attached file, the edits are quite small.
The switch is done based on the intent type value.

The simple keyword passing parameter looks also good in the demo.
More advanced search criteria, like proposed in the current spec, may also be useful at a later stage on once deployment happens and feedback is gathered.
It would also be convenient to enable client applications to narrow down their requests to only images or only videos, like what can be done with mime pickers (image/*, video/*).

Regards,
	Youenn


> -----Original Message-----
> From: Jungkee Song [mailto:jungkee.song@samsung.com]
> Sent: mardi 2 octobre 2012 08:24
> To: FABLET Youenn
> Cc: public-device-apis@w3.org; 'WebIntents'
> Subject: RE: Pick Media Intent Review
> 
> Hi Youenn,
> 
> Sorry for the belated reply. I am not sure you have kept track of the discussion
> in the list, but recently there's been a long discussion about how we better
> handle *multiple* objects in Web Intents data field and the result callback.
> 
> In the course of the discussion, Greg and I thought it would be more natural to
> let the collection of media (images, video, etc.) be like a separate type on its own
> [1]. That is, client-end and service-end expect some gallery-like service
> differentiated from MIME type data exchange.
> 
> I believe it is service provider's decision whether they use "MIME" type or
> "http://intents.w3.org/type/media" type for a service depending on what they
> want to provide.
> 
> Please try the Pick Media Intent demo:
> http://jungkees.github.com/media-intent/
> 
> Please let me know if you have any feedback or further concerns about it.
> 
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0127.html
> 
> Regards,
> Jungkee
> 
> 
> > -----Original Message-----
> > From: FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
> > Sent: Thursday, August 02, 2012 7:03 PM
> > To: Jungkee Song
> > Cc: public-device-apis@w3.org; 'WebIntents'
> > Subject: RE: Pick Media Intent Review
> >
> > Hi Jungkee,
> >
> > Related to MIME type filtering, the HTML input@accept attribute is an
> > interesting example.
> > Developers can tell the file picker which types they are expecting
> > through the accept attribute, with typical values such as audio/*, image/*...
> > The user can override this hint and pick whatever file needed.
> > But in most cases, that is helping to pick the right file faster.
> >
> >
> > As of the difference between MIME vs. "http://...type/media"
> > providers, I am still not sure to perfectly understand the difference.
> > I would expect a "http://...type/media" pick provider to easily
> > provide and be interested in providing "image/*" pick intent as well.
> > It seems also natural to reuse the dictionary already defined in the
> > 'Pick media' specification in both cases for instance.
> > In the context of a 'save' file with MIME/type=image/jpeg provider,
> > one may want to send some properties to the provider in addition to
> > the raw data, like its filename if available.
> > Sure, one could put these properties within the 'extras' dictionary,
> > but it is straightforward to reuse the 'Pick Media' dictionary for
> > that purpose.
> >
> > Regards,
> > 	Youenn
> >
> > > -----Original Message-----
> > > From: Jungkee Song [mailto:jungkee.song@samsung.com]
> > > Sent: mercredi 1 août 2012 13:32
> > > To: FABLET Youenn
> > > Cc: public-device-apis@w3.org; 'WebIntents'
> > > Subject: RE: Pick Media Intent Review
> > >
> > > Hi Youenn,
> > >
> > > Please see inline.
> > >
> > > > Fewer choices, especially if relevant, seems nicer to the end-user.
> > > > Defaulting rules may be easier to define for user-agents as well,
> > > > like pick images on flickr, pick music on play.
> > > >
> > > > Also, it seems good design to enable provider or user agent to
> > > > detect whether a media selected by a user matches the web intent
> > > > client requirements, before actually sharing that data to the intent client.
> > > > If a web intent client only processes mp3 and a user selects an
> > > > ogg file (or worse, jpeg), the web intent provider may be able to
> > > > warn the user before sharing the media.
> > >
> > > Upon the loosely coupled nature of Web Intents, we basically do not
> > prefer to
> > > put much constraints in the intent parameters. Rather, the service
> > > implementation can provide flexible UI to allow users to conduct
> > advanced
> > > searching and data filtering, including the media type selection.
> > > For
> > example,
> > > users can choose "video/mpeg" as a search filter in the service UI.
> > > (I did not consider *explicit intents* here, though.)
> > >
> > > > If not passed through the type parameter, which has its own
> > > > semantics and constraints, that kind of information can fit in the
> > > > extras
> > dictionary.
> > > >
> > > > > > One straightforward option would be to use the MIME matching
> > > > > > type
> > > > > parameter filtering capacity.
> > > > > > A user agent would be able to filter the number of potential
> > > > > > pickers based
> > > > > on that parameter.
> > > > >
> > > > > I think MIME does not give enough information to distinguish the
> > > > > PMI
> > > > services
> > > > > from other intent services.
> > > >
> > > > Can you elaborate on that?
> > >
> > > Using the Pick Media Intent services, users would expect to pick
> > > some
> > useful
> > > metadata along with the media resource. With the services registered
> > with the
> > > type, "http://intents.w3.org/type/media", users can be aware of the
> > possible
> > > such services among various media services.
> > >
> > > Regards,
> > > Jungkee
> > >
> > > Jungkee Song
> > > Samsung Electronics



Received on Thursday, 18 October 2012 12:58:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 18 October 2012 12:58:22 GMT