W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

RE: Gallery API draft review request

From: Jungkee Song <jungkee.song@samsung.com>
Date: Fri, 04 May 2012 22:21:46 +0900
To: 'Greg Billock' <gbillock@google.com>
Cc: 'DAP' <public-device-apis@w3.org>, public-web-intents@w3.org, '̿ Lee' <wonsuk11.lee@samsung.com>
Message-id: <01d701cd29f8$db33b680$919b2380$%song@samsung.com>
Greg,
Thank you for your comments.

> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com]
> Sent: Friday, May 04, 2012 8:40 AM
> To: Wonsuk Lee
> Cc: Jungkee Song; DAP; public-web-intents@w3.org; ̿ Lee
> Subject: Re: Gallery API draft review request
> 
> I have a question about synchronizing this work with the proposal for
> passing MIME types through web intents at [1].

Basically, as the Gallery API uses Web Intents, it means we would align the
type of exchanged data in the request and callback. (MIME type specifier
and any future extension. I am not sure about schema.org we talked at the
last DAP F2F meeting)

> There I describe how to prepare MIME typed data on the client side,
> and didn't address returning data from the service as MIME type. I
> think it'd be best to coordinate this so that any MIME type specifier
> produced a common expectation for any action. For example, something
> that builds on this would be:

Right. The data dictionary for the callback will be defined based on the
reference (MIME type) but would have some more fields to deliver relevant
metadata.

> A service returning MIME type data MUST prepare it in a dictionary as
> follows:
> 
> dictionary MimeTypeData {
>   readonly attribute any content;
>   readonly attribute DOMString url;
>   readonly attribute DOMString filename;
>   // (other attributes may be present?)
> };

Many attributes are present. ;) I am working on it.

> If the MIME type is binary (application/*, image/*, video/*, audio/*),
> then the "content" field MUST be of type Blob. If the MIME type is
> text (text/*, message/*, multipart/*), then the "content" field MUST
> be text.

The draft currently considers image/*, video/* and audio/*, and the content
fields are to be of type Blob. We have discussion about the method of the
content delivery: a Blob and/or a URL. At the moment, I think it would be
better to support both ways like Web Intents leave it to users.

> Either the content or the url field may be filled.
> 
> If present, the "filename" field may refer to the service-side
> filename of the resource passed back, as a hint to the client.

About the "filename" field, you described, "This field's value is not a
url, but is the filename (probably not fully qualified, but simply the name
of the leaf file) of the resource being passed as assigned by the user." 

The Gallery API also requires the name of the item, so the field could be
used in the similar way.

I will update the definition of the data dictionary.

> ---
> 
> This mimics the usage I described for passing MIME types. Do you agree
> that something like this would be a good overall MIME passing
> convention? If so, do you want to add this to the wiki page [1]?
> 
> 
> [1] http://www.w3.org/wiki/WebIntents/MIME_Types
> 
> 
> 
> On Thu, May 3, 2012 at 1:59 AM, Wonsuk Lee <wonsuk73@gmail.com> wrote:
> > Hi. All.
> >
> > Below link is pretty version ;)
> > https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html
> >
> > best regards,
> > Wonsuk.
> >
> > 2012/5/3 Jungkee Song <jungkee.song@samsung.com>:
> >> (DAP) ACTION-533: Jungkee Song to Gather use cases for Gallery API
> >>
> >> Hi,
> >>
> >> Since the last DAP F2F meeting, Wonsuk and I have prepared a draft for
> the
> >> Gallery API, a shelved item for a while.
> >>
> >> In this draft work, we propose to use Web Intents to locate media
> galleries
> >> (no matter whether they are on web or local) and deliver media contents
> >> with metadata. We think that the advantage of this approach is that it
> >> makes integrating with popular services like Flickr, Youtube,
> SoundCloud a
> >> lot easier. We tried to stay with the simple and practical use cases.
> >>
> >> Your review on the draft will be appreciated. Especially, see the
> section
> >> "3.2 Discussion".
> >> Let's discuss.
> >>
> >> * I uploaded the file in the DAP repo:
> >> https://dvcs.w3.org/hg/dap/gallery/index.html
> >>
> >>   Dave, Dom,
> >>     Could you let me know how to put this file on the main page?
> >>
> >>
> >> Regards,
> >> Jungkee
> >>
> >>
> >> Jungkee Song
> >> Samsung Electronics
> >
> >
> >
> > --
> >
> > =========================================
> >    (Wonsuk, Lee) / Principal Engineer, Ph.D
> > SAMSUNG ELECTRONICS Co., LTD. (߲)
> > Mobile: +82-10-5800-3997
> > E-mail: wonsuk11.lee@samsung.com, wonsuk73@gmail.com
> > http://www.wonsuk73.com/, twitter: @wonsuk73
> > -----------------------------------------
> > Inspire the World, Create the Future !!!
> > =========================================
> >
Received on Friday, 4 May 2012 13:22:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:30 GMT