superlifter design notes (OpenVMS perspective)

[Martin Pool]

On 27 Jul 2002, jw schultz <jw at pegasys.ws> wrote:
> The server has no need to deal with cleint limitations.  I
> am saying that the protocol would make the bare minimum of
> limitatons (null termination, no nulls in names).

It probably also makes sense to follow NFS4 in representing
paths as a vector of components, rather than as a single string
with '/'s in it or whatever.  ['home', 'mbp', 'work', 'rsync'] avoids
any worries about / vs \ vs :, and just lets the client do
whatever makes sense.

I don't know a lot about i18n support, but it does seem that
programs will need to know what encoding to use for the filesystem
on platforms that are not natively Unicode.  On Unix it probably
makes sense to default to UTF-8, but latin-1 or others are
equally likely.  This is independent of the choice of message
locale.  I think the W32 APIs are defined in Unicode so we don't 
need to worry.

Quoting, translating, or rejecting illegal characters could all
make sense depending on context.

I guess I see John's backup vs distribution question as 
hopefully being different profiles or wrappers around a single
codebase, rather than different programs.  Perhaps the distinction
he's getting at is whether the "audience" for the client who
uploaded the data is the same client, or somebody else?

-- 
Martin