> Bernd Paysan wrote:
> > I like HTTP more than e.g. the tar format, since it
> > contains attribute: value pairs, and that would allow to make better use
> > of a database-like structured filesystem, where extended attributes are
> > possible.
>
> I like MIME multipart (with Content-Length) even more since it is
> similar, and is also actually meaningful in a file unlike HTTP.
MIME multipart is good, but only as long as the file isn't encoded base64
;-).
> > The only disadvantage is that HTTP has implicit types of
> > attributes (making them explicit, e.g. "int64 Content-Length: 1234")
> > would help generic parsing a lot.
>
> I don't see what's wrong with "infinite" precision. These are files not
> potentially extremely large streams, right?
cat foo/ >bar/
should be able to restore the attributes of all files in foo as is in the
directory bar. Either you implement even the file length in the fs as
string (uuaaah!), or you assign a restricted type to it, like int64.
> > BTW: when you start thinking about a query_attributes(2) call, make sure
> > not to repeat the XInternAtom flaw: attributes are labeled by strings
> > (that's a good idea), but the string isn't used for each command:
> > instead, the application assigns a unique number to each attribute name,
> > and sends that pair to the filesystem. It subsequently uses it's own
> > numbers to name the attributes.
>
> Are you describing the flaw or the way it should have been implemented?
I describe the way it should have been implemented. XInternAtom queries
the X server for the number instead of forward-assigning it by the client.
Since filesystems are often used remotely, all filesystem semantics should
follow these design guidelines (no round-trips when avoidable).
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/