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

[Josh England]

address@hidden wrote:
> 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.

I agree with this, and what you said in your last post.  Asking tla to
handle translating different metadata types to their functional
equivalents on every platform is just asking for trouble.  I think arch
should transparently handle *very few* metadata types implicitly: file
permissions, optional file ownership, and optional CR/LF issues.  All of
these translate well enough between platforms.

For other metadata, consider again the single generic metadata string.
This string could be arbitrarily long. tla would only need to diff it to
tell that the metadata for any given file has changed.
The string itself could be anything.  For example, a file called
/tmp/foo could have a metadata string like this:

"clrf=unix,xattr::joe=bob,win32=ignore"

or this:
"<?xml version="1.0"?> <file_attr> joe <value> bob </value></file_attr>"

or even this (which is probably a bad idea):
"#!/bin/sh chown 0:0 ${ARCH_FILE}"

The point is, you could do ANYTHING with that single string, and tla's
job would be very easy: tell you if the string has changed.  This is SVN
properties on steroids.

Its alright for people to want the software to transparently handle
every situation known (and unknown) to man, but it is simply not very
feasible.  Software of this nature should really follow the 'Keep It
Simple' philosophy, which I think tla has done a great job of so far.
Giving tla this kind of generic store/retreive of a simple string would
*enable* some very cool things to be done by the user in surrounding
wrappers and hooks, while keeping the core tla engine fairly simple.  I
could envision any number of people building some very cool mechanisms
on top of this kind of feature.

-JE