On 27 Jul 2002, jw schultz <[EMAIL PROTECTED]> 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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
