I don't think we want to be doing this for backups.
An entire filesystem is not a compound document!
> > 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.
>
> Yes. But since filesystems should allow remote operations, some sort of
> forward-assignment should be possible. Perhaps only per transaction, and the
> server responds with the real numbers ("if you don't want to do another
> forward assignment to the foo-bar atom, here's what I use to call it"). The
> client can switch over to a less data-intensive protocol after a round trip
> delay, but isn't delayed initially.
Nice. Alternative: half the numbers are reserved for forward-assignment
by the client, half by the server. The server can refuse to accept
client-assigned numbers at any time, and it also returns the
server-assigned numbers with client transactions using those numbers.
So things start quickly, and the client can replace its assignments with
stateless server assignments within one round trip. If the server
decides not to maintain the state, or reboots or whatever, it can drop
client-side assignments at any time and the client will recover with a
retry if it's just starting out. So the server can't get overloaded.
Rather like HTTP 1.1 can drop connections when the server decides it
wants to, but with even less state than TCP ;-)
> The other idea was to not even bother with the strings, but only take
> a hash key and pass that around, including the risc of
> collisions. Well, I don't like the idea of having two keys magically
> collide ;-).
No I don't like that idea either.
-- 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/