RE: Pick Media Intent Review

> -----Original Message-----
> From: FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
> Sent: Thursday, October 18, 2012 9:58 PM
> 
> 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.

Throughout the discussion, we've come to a consensus that the use case for a
single-mime service and multiple-media service (gallery-like service) would
be fairly distinctive [1].

> The situation would look bad though if Flickr and Picasa were not
> supporting at least one common picker.

>From the above reasoning, flickr and Picasa would rather provide
multiple-media picking service as their gallery-like service which Pick
Media Intent clients would expect in that way as well. i.e., use cases where
user really want to pick a single mime object would be sort of distinctive
against the gallery services.

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

Currently, Web Intents wiki describes the guideline for mime data [2].

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

I think that's possible if both client and service assume they would expect
both media-intent type and video/* type at the same time. However, the
clients which were developed without knowing of all the meta data defined in
media-intent object might encounter quite a lot of undefined fields in
result objects.


> 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/*).

Assuming that the use case for a single-mime service and multiple-media
service is distinctive, I don't think we get much benefit by filtering out
the services by mime type in media-intent service case. I would like to hear
opinion from Web Intents folks for this. I hope Greg catches this mail.

Thank you for the comments, Youenn.

Regards,
Jungkee

> 
> Regards,
> 	Youenn


[1] http://lists.w3.org/Archives/Public/public-web-intents/2012Sep/0067.html
[2] http://www.w3.org/wiki/WebIntents/MIME_Types


> 
> 
> > -----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.ht
> > ml
> >
> > 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 Friday, 19 October 2012 09:31:51 UTC