1. I'm not convinced it should restore all _attributes_ [uid etc.]. If
receive an albod in the mail and save it, I don't expect to see your
uids in there. Not even if I'm root.
2. This came from a mention of an HTTP-style header: "Content-Length:
12345", so it's given that it'll parse a sequence of digits.
If you go around defining types like "int64" the kernel would have to
parse the type string and support all the ones everyone else uses.
In which case there's a "largest supported size" that everyone has to
agree on, or get a parse rejection. Why not forget the type restriction
and just agree on a largest number?
One reason I can think of: so you detect max-size incompatibility early
between systems, rather than getting a surprise failure the first time
you try to transfer a large file.
> 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).
Pros and cons. Forward-assignment lowers communication latency (which
is really noticable for non-local X apps), but requires the server to
maintain and look up per-client state.
-- Jamie
-
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/