[ANN] bzr.webdav: a writable hhtp transport

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> 
>>John Arbash Meinel wrote:
>>
>>>>Probably we could do some alternative optimizations for transports that
>>>>don't support append. For example, we would have already downloaded all
>>>>of the knit index, so we know how to update it, rather than downloading
>>>>the whole thing again.
>>>>
>>>>But the expensive one is the knit data file, and that we haven't
>>>>downloaded yet.
>>
>>If we have a local copy of all the data in the remote file knit, and we
>>have a write lock, we can regenerate the knit from the index, without
>>retrieving it, and then upload it.
>>
>>Aaron
> 
> 
> That may still require a readv() because we may be missing things. Also,
> things may be sorted in a different order on the remote side. So it may
> involve quite a bit of reworking.

If the pieces are the same on both sides, it's probably not a big deal--
we can just reorganize things at the byte level.  If one has snapshots
and the other doesn't, that's more work.

> It also violates our layering, because Transport isn't supposed to know
> anything about the contents of the files it is moving around.

Oh, no question.

> The best I can think of is having a 'supports_append()' flag as part of
> Transport, and then update any other code that uses append to special
> case based on what we are trying to do.

Yes, that kind of thing makes sense.  But I agree, it's non-trivial.  If
only people could all use sftp...

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFE6zW/0F+nu1YWqI0RAjCXAJ4geCiqx7REtnuSGEZBb44CK0yQ/gCfehwu
6izW1sgCSlZ9CTYLvTm49zY=
=DxDH
-----END PGP SIGNATURE-----