On Mon, Apr 04, 2005 at 09:08:07AM +0200, Ulf Ochsenfahrt wrote: > On Sun, 2005-04-03 at 13:35 +0200, [EMAIL PROTECTED] 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
pgpRyscK5QyMl.pgp
Description: PGP signature
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
