W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Systematic access to media/plugin metadata

From: Danny Ayers <danny.ayers@gmail.com>
Date: Wed, 13 Apr 2011 13:19:52 +0200
Message-ID: <BANLkTikm4QF-idz6YEK5j3Ev-R7SDd3aOw@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, public-html@w3.org
On 13 April 2011 12:49, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Wed, 2011-04-13 at 12:01 +0200, Danny Ayers wrote:
>> > As far as I can tell, the use cases you included called for browser UI
>> > features--not for an API.
>> I don't think so...the UI parts for directing someone to a hotel or
>> alerting them to something in a photo could be handled by regular
>> DOM/HTML, <canvas> or SVG. The only bit that can't easily be fulfilled
>> right now is access to the metadata.
> If the scenario is that someone puts a image with metadata on a server
> and without the author doing anything else, the browser can alert the
> user about stuff, then it's about a built-in browser feature that
> doesn't have expose anything to JS.
> If the scenario is that someone puts an image with metadata on a server
> *and* supplies a JavaScript program that uses DOM/HTML, canvas or SVG to
> alert the user about the metadata, the author controls both the image
> and the alert mechanism, so the author might as well extract the
> metadata on the server side (like e.g. Flickr does) and transfer the
> extracted data to the browser using whatever existing means.

Thanks - I see your point now.
It was the second scenario I had in mind, but with the consideration
that the originating server for the image/media object may not be the
same as the one with the script.

> The server is a notable part of a Web app. I don't think it is a useful
> goal to seek to move everything to the browser side.

I agree, but given that typically the image/media object will be
transferred to the client for rendering, it seems reasonable to be
able to access any embedded metadata there too.

For popular formats it is commonplace to have other aspects of the
data handling delegated to the client, e.g. PDFs are served as-is and
the browser will take care of things like pagination within the PDF.
You don't often see the pages of a PDF split and converted
server-side. Why should the metadata be treated as a special case?


Received on Wednesday, 13 April 2011 11:20:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:12 UTC