RE: Pick Media Intent Review

Hi Youenn,

Thank you very much for your feedback. Please see inline.

> From: FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr] 
> Sent: Friday, July 27, 2012 4:16 PM
> To: public-device-apis@w3.org
> Subject: Pick Media Intent Review
>
> Dear DAP WG,
>
> I took some time to go through the Media Pick Intent specification.
> This specification seems already in good shape and is easy to read, which
is good!
>
> Please find below some comments that came to mind when reading the spec.
> Even though I certainly miss some context information, I hope that this
feedback will be of some use.

Your feedback is valuable!

> I will try to send some feedback to the Web Intent spec as well.
>
> Regards,
>                Youenn
>
>
> 1. Media Type Filtering
> One important filtering case may be based on media types.
> Requesting images or mp3 may be different. This may lead a user to select
different providers.
If a provider supports several media types, the provider may use a different
initial UI depending on the suggested type: initial view could show ‘Music’
or ‘Pictures’ folder…
How would happen that kind of filtering?

A specific intent is identified with action/type pair and it has a
designated URL. My intention on the flat style type definition is to keep it
simple since service providers still can provide intuitive media services
shown in the picker.

For instance, a media service provider, SP-PMI.com, can provide,
  "PMI Music Repo", at http://SP-PMI.com/audio/
  "PMI Video Repo", at http://SP-PMI.com/video/
  "PMI Media Repo", at http://SP-PMI.com/media/ (Providing all three)

The picker shows all the possible "http://intents.w3.org/type/media" type
services, and it is a user's choice which specific service (type) she will
go for.

It can be an option to introduce hierarchy in type definition such as,
http://intents.w3.org/type/media/audio
but I think it has only a small advantage like reducing the list of services
in the picker while adding complexity.


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

> The action value could be changed to something more precise
(http://webintents.org/pick/media?).

"action" and "type" in Web Intents have distinct meanings and roles.
"action" specifies the "verb" part and "type" comes under "noun" part.

> 2. Keyword filtering
> While I see a potential use for the ‘limit’ member, I am less sure about
the search feature (filters and search parameters).
> Would filtering be best handled by the web intent provider itself, with a
UI well-known to the user?

In fact, I had a same feedback in the WG. So, the "search" is the part that
I am still finding relevant use cases before dropping the whole
functionality.
In the current draft, however, the search keyword and filter attributes are
simply hints for the service developers to consider them as user's initial
intention.

> 3. Persistency
> In the case a user is doing a photo album or an image mosaic, she may
select some images iteratively.
> In that case, the same intent provider may be called more than once by the
same web application.
> It would be very handy if the provider could keep some knowledge of the
past interactions.

Yes, it is a topic that is still in discussion within the group.
By the way, I suppose one way is that web application can hold the media
object data (including URL and blob) in local DB for persistent user
experience.

> One option would be for providers to use some user-agent cache techniques:
to keep filtering keywords, existing > displayed images…

In my opinion, cache has a downside regarding privacy handing over unwanted
history of user actions to the service end.

> Another option would be to allow the user agent to reuse the past provider
page (e.g. stored in the browser page cache) , for instance if the same
Intent object is used several times to start an activity.
> I am unsure whether the Web Intent specification enables or precludes this
particular behavior.

I think we need more discussion on this. ;)

> 4. Blobs & URIs
> There are currently two content access mechanisms defined in the pick
media intent spec: blob and URI.
>
> 4.1
> In the case of a local media picker, the media content may be retrieved
using the File API.
> In such a case, it may be nice to provide the data as a blob and not as a
URI.
> The current specification states that the URI is mandatory which may not
be practical in that case.
> Would it make sense to state that at least one of either URI or blob
member is required?

Yes, I agree. Even though a local service can use "data URI", it makes sense
that an app requires only a raw data on purpose.

> 4.2
> I wonder whether it would be convenient to let the web intent client ask
for either blob or URI as data access.
> Otherwise, it will always need to handle both cases.

Good point. I will think about it.

> 4.3
> The security implications are important for media since it may make
difficult some media processing capabilities such as canvas, web audio
API...
> It would be interesting for web intent clients to state whether they want
‘full access’ to data or not.
> At first I was thinking that this information could be communicated as ‘do
you want URI or Blob’, but the separation is more subtle than that.
> Maybe the real issue is deeper and should be treated at another layer.
> Anyway, if a web intent provider knows what access type is needed by the
web intent client, the provider can agree/disagree to that access type.
> If agreeing, the provider can select the best way to transfer the data
(XHR blobs, URIs, ArrayBuffer…) so that the client can readily use the media
content.

I understand what you are thinking about. Let me take some time on this.

> 5. Media dictionary
> 5.1
> There are four mandatory attributes (content, description, title and
type).
> I understand why content and type are mandatory but I wonder why both
description and title are mandatory attributes.
> For instance a local file media picker may only know file names, but not
description or title.

I agree.

> 5.2
> Some properties but not all have a meaning well defined in the Media
Ontology core set.
> If that is the case, would it make sense to make precise reference for
each of these fields?

I am not sure whether I exactly got your question. Do you mean it will be
good to specify in the spec that the relationship of each field in the PMI
and that of the core set?

> 5.3
> Would it make sense to align the filename property to the name property of
the File interface?

File interface in File API defines the "name" attribute as a DOMString type
and take only the name of the file (without the path information.)
Meanwhile, there can be use cases in web applications to show the file path
of the local storage. However, I think it is redundant to keep file name and
file path attributes in the Media dictionary at the same time. Also, as
described in the draft, it can deliver any additional URL information in
remote service case.

> 5.4
> I am curious about the reason to restrict the media id representation to
URI.

Sorry for the early update of the ED draft ;)
http://w3c-test.org/dap/gallery/

The id field is dropped from the property set. I think the "content.URI" is
enough to indentify unique media. Also, we can use "content.URI" for local
storage as well. (e.g., local://path/to/the/file.*)

> 5.5
> If it makes sense in the future to create a save/share media intent API,
it may be nice to share the Media dictionary members for both pick and
save/share intents.
> Is it envisioned as part of the design of the Media dictionary?
> Is it a work that is envisioned within the WG?

Yes. I will definitely deal with the share/save intents in the next version
after making PMI in a good shape. There is no difference in the Media
dictionary definition.

> 6. MediaError 
> It seems like the MediaError dictionary could be applied to about any web
intent provider error message.
> Would it make sense to reuse that pattern for other intents and actually
advertise that pattern somewhere? As a best practice? As an interface?

Good point. The best practice approach would be helpful to service
providers.

> 7. Typo
> Section 3.3 user agents -> user agent

Thank you.



Regards,
Jungkee

Received on Friday, 27 July 2012 13:47:50 UTC