On Thu, Feb 19, 2004 at 10:23:27AM +1030, Brett Lymn wrote:
> If there was to be a version bump for RPC2 then perhaps it would be an
> ideal time to address some LP64 issues as well?  I am not certain if

Actually... making RPC2 64-bit clean doesn't change anything on the
wire. The first goal would be to simply clean up the source so that the
RPC2_Integer is in fact defined as a 32-bit integer instead of the
current '32-bit on a 32-bit machine, but 64-bit on a 64-bit machine'
behaviour of the long integer datatype. This can be done without
changing anything in either the API or the on-the-wire protocols.

The second step would be to identify if/where it might be useful to have
actual 64-bit datatypes, things that come to mind are the file-offset
and length values that we pass to the SFTP side-effect for file
transfers. Most of these are simple API changes which will only require
a recompilation of Coda clients and servers, but most likely no actual
on-the-wire protocol changes.

Finally, the fact that we can deal with large files could be propagated
into the existing rpc2 protocols. This could be done by introducing new
opcodes (similar to stat(2) vs. stat64(2)), which allows old clients to
remain using the new servers. The question by that time will really be,
is is really worth the more than 5 minute wait to access (or save) a
2GB+ file that is not in the Coda client cache.

Jan