Re: Pick Media Intent Review

On Mon, Oct 1, 2012 at 11:24 PM, Jungkee Song <jungkee.song@samsung.com> wrote:
> 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/

Demo looks good, Jungkee! Just tried it out.

Thanks for the link!


> 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 20:42:41 UTC