gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Re: arch with 'special files'


From: tomas
Subject: Re: [Gnu-arch-users] Re: arch with 'special files'
Date: Tue, 5 Apr 2005 11:28:38 +0200
User-agent: Mutt/1.5.3i

On Mon, Apr 04, 2005 at 09:08:07AM +0200, Ulf Ochsenfahrt wrote:
> On Sun, 2005-04-03 at 13:35 +0200, address@hidden wrote:
> [...]
> > 
> > [native metadata depending on system]

[...]

> tla should support different os specific metadata storage
> implementations, in particular linux xattr and MacOS whateveritscalled

They have it with `forks´, but I think this is a bit more extensive
than just the kind of metadata we're talking about here (basically
--disclaimer: I'm not a MAC guy-- I think they view files as a kind
of directory with different parts inside. For example you can have
an executable with different forks for different processor types).

> (MacOS also has a metadata thing, doesn't it?) and Windows
> somethingsomething (is there a win equiv.?). It should also have a user

On NT, at least I think yes. I don't know about later Windows, thankyou.

> interface for querying and setting metadata (so tla-specific scripts can
> rely on transparent cross-platform behaviour). In case the filesystem
> doesn't support it, tla will have to fallback onto a file-based storage.
> 
> tla really should integrate with platform-specific tools.

This sounds nice, a bit as though it came from marketing dept ;-)
Imagine you are on system foo, check in and check out to system bar.
Would you try to map attributes from system foo to those semantically
euqivalent on system bar? Maybe foo and bar have both the concept of
a ``file owner´´. What if foo limits the owner to six capital letters
and on bar it's a 64 bit unsigned int? You get the idea.

Or do you keep for each (potential?) system involved a separate set
of attributes, with somewhat overlapping semantics?

As I put in on another post: I do understand pretty well why some more
thinking is in order.

My favourite (but note: my position is `mostly lurker´ :-) would be
to provide the mechanism (attribute storage and retrieval, *maybe*
some kind of type/constraint system for names/values), and leave
*most* of policy to the app/manager (except maybe a small set of
Arch blessed attributes, some of which we have now) through the
use of hook scripts.

> One piece of metadata would be the id,

This one is special, I think.

>                                        another would be line-ending
> behaviour (something like force-lf, force-crlf, error-crlf, ...), with
> no setting implying standard behaviour (do nothing).

Policy, policy. Per project, per user, whatever.

> I guess the keys for these should all start with x-gnuarch- or gnuarch-
> to avoid name conflicts.

You are thinking of MIME representation, are you?

Regards
-- tomás

Attachment: pgpgoI0xibSnr.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]