RE: Draft draft of coming sftp revision...

[Richard Whalen <Whalenr%process.com@localhost>]

I think that #2 is cleaner, and should lead to fewer implementation errors.

The SSH_FXP_EXTENDED 'text-seek' message needs a file handle.


----- or #2 -----

"Servers SHOULD correctly process multiple parallel
 reads correctly in this mode.  However, if the client
 recieves SSH_FX_OP_UNSUPPORTED when attempting multiple
 parallel reads, it SHOULD fall back to serial reads."

"Clients SHOULD use the SSH_FXF_APPEND flag to append
 data to a text file rather then using write with a
 calculated offset.

"When a file is opened with the FXF_TEXT flag, the
 offset field in both the read and write function
 are ignored.

"To support seeks on text file the following
 SSH_FXP_EXTENDED packet is defined"

"string 'text-seek'
 uint64 line-number

"line-number is the index of the line number to
 seek to, where byte 0 in the file is line number 0,
 and the byte directly following the first newline
 sequence in the file is line number 1 and so on.

"Servers SHOULD support at least on 'text-seek' in
 order to support resume.  However, a client MUST
 be prepared to receive SSH_FX_OP_UNSUPPORTED when
 attempting a 'text-seek' operation.  The client
 can then try a fall-back strategy, if it has one."

So what do people think?  I think I'm leaning towards
#2-- it doesn't involve overloading the meaning
of the FXF_APPEND flag, which I think is a cleaner
design.  It also doesn't have the restriction about
seeking position 0.  Additionally, I think it makes
the calculation of where to seek less error prone.

Thanks again for your feedback.

- Joseph