On Aug 29, 2007, at 2:06 AM, jsnx wrote:
On Aug 24, 3:55 am, [EMAIL PROTECTED] (David Leimbach) wrote:
On 8/24/07, jsnx <[EMAIL PROTECTED]> wrote:
On Aug 23, 3:35 am, [EMAIL PROTECTED] (Steve Simon) wrote:
I'am not trolling, I just don't see their efficacy in plan9.
I don't see how to architect the system I discussed without
attributes.
Build yourself a file server that provides the environment you
want with
attributes... don't inject it into the core system. Store it for
real in
fossil files with a certain format.
Done?
If I want to have a system with the features of two distinct
filesystems, what then? Attributes allow for composition, whereas the
FS oriented approach appears not to.
I apologize for coming into the discussion a bit late. But I
always wanted
to share the following observation: metadata seems to be very
confusing to
an average joe. And when I say metadata I mean all
metadata, not just resource forks and attributes. Time and again I've
seen PC users name their digital picture (or at least directories with
the digital pictures) <date>_<place_taken>. Why? Well, because
even though date and time are part of the metadata in pretty much
every filesystem these days it is extremely difficult to make sure that
all the tools handle them and preserve them just the way you want it
to be
(think about the time picture was taken vs. the time the file was
created vs. the time it was last updated or even accessed).
On top of the constant paranoia (Quiz-1: what's the option for cp to
preserve the timestamp?) the metadata approach makes it very
difficult to manipulate collections of files. Quiz-2: what's the
moral equivalent
of doing:
$ cp 09_*_2007*.jpg ~/USA_tour
if I didn't have date as part of the name?
These usability issues with even the most established bits of
file metadata such as date, time, owner, etc. show up often enough
to make one think of if not abolishing metadata all together, at least
not proliferating it any further.
I would have to write (or obtain) a TeX fs, a SVN fs and then a TeX-
SVN fs if I wanted to have those feature sets independently, if I am
understanding you correctly.
The problem you seem to be alluding to is genuine and I'll try to
paraphrase it in order to see whether we're talking about the same
thing. Suppose you have a collection of leaf-node objects that
you can group together in a number of different ways. Suppose
also that these groupings are mostly orthogonal to each other.
Now, if you express objects as files -- what is the most natural
way of expressing various groupings? To make it even more clear
here's a practical example: in my build system I have to produce
binaries for SPARC and x86 running under Solaris and Linux
and each of those binaries either built for debugging or with
maximum optimization. My objects are, obviously, files
but how am I supposed to structure the groupings? It looks like
three levels of subdirectories should do the trick giving me
names like:
sparc/linux/opt/binary
Now, of course, even if we put aside questions like why not
linux/sparc/opt/binary, we still have to figure out how to handle
the case where the very same physical binary file happens to
be a fat binary that can run on both SPARC and x86 Solaris
OSes. Where should it go? Should we symlink to it from
"the other" place? Questions like these seem to call for tagging and
filter filesystems (see my previous question in this very thread).
The scariest part is that they also come dangerously close to the
oldest argument in the OS design history: filesystem abstraction
vs. database abstraction for managing persistent data.
Your hypothetical problem seems to fit exactly the same profile: your
leaf-node objects are lines (or perhaps even sets of TeX lexems)
and the grouping can either be determined based on which SCM
delta a particular object belongs to or where it fits in a tree-like
TeX document structure.
The problem is genuine, and I don't know the right solution for
it, but somehow I don't think the metadata would help here. It seems
to me that you could be confusing a building block for a proper
solution (e.g. tagging) with the solution itself. After all, if I can
convince you that extended attributes ARE just a building block
it shouldn't matter how they are implemented as long as the end result
works properly.
And as for implementation -- David's proposal seems to fit the bill
perfectly.
Thanks,
Roman.
