Re: new mime detection approach



El mié, 14-01-2004 a las 12:54, Alexander Larsson escribió:

> How would such a metadata system work? If it uses a file per file, or
> EAs then it would instantly be as slow as sniffing.

This assumes a certain, flawed or biased, implementation of EA or XML
files, biased against them.  The ideal file-based implementation would
use one XML file per directory and write locks (making large directory
reads for metadata REALLY fast).  The ideal EA-based implementation
would leave the optimization to the file system (EA-supporting FS
implementations already are taking care of this issue) perhaps being
even faster than the XML option.  I recognize that reading file
extensions would be marginally faster (not 400 times) than reading MIME
types from an EA store, but the usefulness of the EA store suddenly
makes possible to store lots of things for which you previously had to
look on other parts of the disk, actually enhancing your possibilities
as a developer while keeping the speed to yourself =).

>  If it used a
> metadata system with e.g. one file per directory it could be fast, but
> that adds a *lot* of complexity with locking and consistancy handling,

The only thing you need to do regarding locking is:

lock(metadatafile)
do your thing
unlock(metadatafile)

that's it.

You can still use EAs. EAs will also be supported by the GNU file utils
and tar and the like, and I sincerely don't think a metadata file would
ever be supported by them (other than collaterally).

The important issue is:

* you can use EAs where they are available, and use file type detection
where they aren't - you can leave the details for other people *

> file permissions,

This issue has been cleverly solved by others.  Of course, I know
there's no solution for the case of a file-based metadata
implementation, but then in those cases you could choose to store only
"unclassified" information, such as the MIME type.

>  and possible out-of-process communication. There has
> been thoughs about a common metadata system, but they are far from near
> implementation,

The Mac has a working, fine metatada implementation.  Windows XP and
Longhorn both have metadata implementations in the form of streams
(Longhorn even has WinFS).  The fact that you think no people from the
FLOSS camp have tried to implement it doesn't mean it's impossible to do
(in fact, people like Hans Reiser - ReiserFS - and Seth Nickell -
Storage - have done great advances in the field).

>  and there are many issues to solve.

I don't think so.   Of course you're welcome to digress =).

> 
> Additionally a metadata-based system would mean any non-nautilus
> operation on the file could make it drop the metadata,

I agree on this if you used an XML implementation.  This can't happen on
an EA file system.

>  leave metadata
> around forever, 

See previous sentence.

> or make the metadata stale.

See previous sentence.

>  It would also have problems
> with read-only media and probably other complications.

Why would it have problems with read-only media?  If the media is
read-only, any updates to the metadata store HAVE to fail silently. 
What's the problem.

This sounds like FUD.  Sooner or later it will happen: a metadata system
will have to emerge, and while it hasn't, it would be wise to take the
lead instead of ignoring it.  Being leaders ensures continuous attention
from the mainstream, helps you become the one that sets the standard,
and has other advantages.  It's in our hands to be leaders or
followers.  And it doesn't sound like we're being leaders (see
Longhorn).  We're still on a time frame to beat Longhorn on a workable,
fundamentally correct, functional, fast implementation of a metadata
system (by putting at least Storage and EAs together).

(I feel that the role of Storage as an additional layer above the file
system is a little bit heavy.  I'd rather have Storage *cache* the
metadata for which the file system is actually the primary source, and
update the file system whenever a new file comes into "acquaintance"
with Storage.  Storage should also have the role to provide APIs to read
and write in a standardized way to the metadata store, which ultimately
would be the file system, NOT Storage's database.  Storing things like
file comments, links to people objects, links to mail messages, stuff
like that, stuff that will enrich the desktop experience much, much more
than wondering whether Nautilus should detect files by content or by
type).


> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl redhat com    alla lysator liu se 
> He's a bookish soccer-playing werewolf gone bad. She's a strong-willed snooty 
> safe cracker descended from a line of powerful witches. They fight crime! 
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list
-- 
	Manuel Amador (Rudd-O)
	GPG key ID: 0xC1033CAD at keyserver.net

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]