Re: Is there proposal of accessing metadata of media files?

Hi Dan!

On Oct 13, 2009, at 20:23 , Dan Brickley wrote:
> Do you have any more details on DAP's Gallery requirements?

We're still working on that and refining. At this point we're looking  
at them from a rather high level.

Basically, a device may contain several galleries. For instance, on  
the iPhone, when you take a picture it goes into a specific, well- 
known location. Other apps can have access to that and use it even  
without having access to the private space of the camera application.  
Same thing for your MP3/AAC library and a bunch of other things (which  
could include for instance Flickr exposed as a Gallery).

So at a technical level a gallery doesn't have to be more than a part  
of the file system which you can access without knowing its location  
(and without needing full access to the FS), each gallery being a more  
or less coherent collection (the idea is not to have one gallery with  
all the images, and another with all the videos as you might want to  
keep the "Holiday Picasa" gallery and the "Hot Dahut Personals"  
gallery separate), and each item holding metadata.

> Is that the latest word on the topic? What content types are in scope
> for these galleries? anything that might live in a filesystem? Is it
> supposed to allow for remote services too (eg. a list of media
> streams).

What content: I would expect only media, but I am not convinced that  
we need to limit it in any way. If you insist on having a gallery of  
spreadsheets, be my guest (preferably at someone else's house though).  
Remote services: yes.

> Context: Lately I have been looking into 'media centre' APIs (xbmc,
> boxee, itunes etc) for the NoTube project. These typically address
> some or all of the above requirements plus a bunch more (eg.
> pause/play/stream etc content).

Pause/play/etc. would be separate — but it would just be wonderful if  
you were to volunteer to provide an overview of all this to the DAP  
WG :)

> I am working up a proposal to expose some of this functionality using
> XMPP (aka Jabber), such that an EPG or content browsing app running on
> a phone could communicate over XMPP to a TV or media centre.

That's very interesting.

> The use
> of XMPP for messaging is to avoid the difficulties of exposing
> HTTP/REST services in a home or NAT setting, and an attempt to
> sidestep the need for devices to be on the same location network. My
> impression of DAP is that it's more for device-local access (so less
> concern for async interfaces perhaps?). Is that correct?

DAP is about device access, and that require async interfaces in a lot  
of cases. In theory, anything that could trigger a security warning  
should be async (so that you don't lock up the interface waiting for  
the user to decide if she should grant access), and a lot of device- 
local operations are slow enough to warrant async anyway. So that's  
not a problem.

In this case, it is as much about local device functionality as it is  
about local device *knowledge*. You can put all that you want locally  
or in the cloud, but someone has to know where all of it is so that it  
can be federated easily when need be. That someone ought to be the  
user agent. It could be a new approach to mash ups.

> If any of this is close to our concerns, let's stay in touch..

Join us! Together we can rule the web as, errr, funny guys!

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 15 October 2009 07:50:05 UTC