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, 2 August 2012 10:03:48 UTC