Re: [patch] Add a timestamp to metafiles

[Manuel Amador <rudd-o amautacorp com>]

El vie, 12-08-2005 a las 23:50 +0200, Christian Neumair escribió:
> Am Dienstag, den 09.08.2005, 11:20 -0400 schrieb Joe Shaw:

> - After collecting the metadata, we set the "metadata-timestamp" xattr
> of the file.

btw, now would be a great, great time to start agreeing on namespaces
and data types and formats for EAs. Yesterday would have been even
better.

fd.o may be helpful in the process... just try to get a very quick
agreement.

> 
> - Any metadata xattr value is supposed to be a string, which can then be
> used as tooltip etc.. I don't think it's worth adding images or other
> data types, considering that we already have a thumbnail spec and you
> typically want info like "Author", "Subject", "Width" etc..

Yes, but with the advent of EAs and its locality (nearness to the data
they enhance) advantage, it may be time to revise the thumbnail spec to
allow saving thumbnails directly in EAs.

> 
> - Providers will probably be added by modules, so that 3rd party
> developers can add their own
> 
> - A provider is essentially a gobject which can propagate metadata
> changes through its properties. After a change (which always happens
> during a requested metadata collection) we
> 
> a) call all metadata clients that were registered against the URI/MIME
> type/attribute in question (all of which are optional, so you can listen
> to all metadata changes as well)

It would be nice if both nautilus and gnomevfs-using apps (maybe even
gtk-using apps) branded files with an EA containing its mime type.
Well, perhaps not Nautilus, but at least apps.  This could end once and
for all the "my glade files are detected as XML" problem, and provide a
very cool way to wean off our dependency in file extensions as well.
Not to mention how fast Nautilus could get on large directories if it
didn't have to sniff for content.

> 
> b) set the xattr "metadata-$provider-$property" to the value we retreive
> from our gobject.
> 
> I'm not yet totally sure on the architecture and will probably encounter
> many pitfalls (wrt threads I'm a loser), but in the long term I think
> the library will stabilize and provide the foundation of future metadata
> fame. I'm very keen to get some feedback from experienced metadata
> hackers, especially whether they like the proposed architecture.
> 
-- 
Manuel Amador                   <rudd-o amautacorp com>
http://www.amautacorp.com/            +593 (4) 220-7010