- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 13 Apr 2011 21:54:37 +1000
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Danny Ayers <danny.ayers@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, public-html@w3.org
On Wed, Apr 13, 2011 at 8:49 PM, 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. > > 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. There are actually browser plugins that expose EXIF and similar image metadata, see https://addons.mozilla.org/en-us/firefox/search/?q=exif&cat=all&x=0&y=0 . I don't think it's unreasonable to expect the same thing for video and audio. Cheers, Silvia.
Received on Wednesday, 13 April 2011 11:55:24 UTC