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 Tuesday, 2 October 2012 06:24:52 UTC