[ANN] bzr.webdav: a writable hhtp transport

[Vincent LADEUIL]

>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:

    jam> Vincent LADEUIL wrote:
    >> Hi all,
    >> 
    >> https://launchpad.net/products/bzr.webdav
    >> 
    >> is a plugin which implements the DAV protocol client part
    >> (well, the part needed for bzr at least).
    >> 
    >> Its performances are horrible, bzr have recently switched
    >> to the append-to-update approach which means that each
    >> time a file is updated it should be downloaded, updated
    >> locally, uploaded.

    jam>  Well, the  old  format *always*  had  to do  'download,
    jam> update, and upload'.  The  new format doesn't, so on all
    jam> transports that  support it, we can save  the download &
    jam>  update time.  That is  why we  switched,  because Weave
    jam>  performance is  very  slow precisely  because of  these
    jam> download+update+upload steps.

Yes  I understood  that, I  hope you  didn't take  my  remark too
seriously, it was not meant  to harm anybody. It's just that when
I  realized,  during   the  implementation,  that  the  resulting
performances will so far away  comparing to bzr that I feel quite
bad for a moment :-)

    jam> Probably we could do some alternative optimizations for
    jam> transports that don't support append. For example, we
    jam> would have already downloaded all of the knit index, so
    jam> we know how to update it, rather than downloading the
    jam> whole thing again.

I  was thinking  about  caching locally  every  file passing  the
'get', but :

- I'm not sure I can miss some bits,

- I'm not sure  you already have some caching  implemented that I
  can reuse,

- I was willing to make it work before making it fast.

    jam> But the expensive one is the knit data file, and that we
    jam> haven't downloaded yet.

    jam> I'm pretty sure we are reasonably good about only doing
    jam> 1 update per knit file. Because even doing N appends to
    jam> the same file is a lot slower than doing 1 append of
    jam> length N.

    jam> Does WebDAV not have any sort of Append command?

Don't hold your  breath. I don't have the  reference handy, but a
draft  exists   (dated  07/2006),  proposing   APPEND  and  PATCH
additions to DAV.

Ha ! I know I had pasted it somewhere in the code:
www.ietf.org/internet-drafts/draft-suma-append-patch-00.txt

    >> This plugin was born today (well, last week), give it some
    >> time to mature. If you care about your data, make backups.
    >> 
    >> Still reading ? Ok, the good news then.
    >> 
    >> The good news is that the performances can hardly be worse
    >> and that there is some solutions to improve them.
    >> 
    >> The other good news is that it has been tested on DAV
    >> enabled Apache 1.x and 2.x and comes with a transport test
    >> server that is able to pass the 'bzr selftest' (minus two
    >> tests: lock_write and copy_to for which I need some
    >> lights).

    jam> If you want more interactive help, I'm usually available
    jam> on irc during US work hours, and there are usually
    jam> others their as well.

See you there tomorrow then.

    >>  The intent of this plugin is to offer a solution to
    >> people who are behind firewalls (the real hard to get
    >> through variety) or those who can't install a smart
    >> server.
    >> 
    >> Enough hype.
    >> 
    >> I welcome any kind of remark on any subject (well,
    >> somewhat related to the plugin).

    jam> Just as good natured poke, you used 'hhtp' again in the
    jam> title :)

lol, I should teach my ispelll about that one...

    >>  Happy reading, reviewing, testing,
    >> 
    >> Vincent

    jam> I'm downloading now, I'll let you know if I see
    jam> anything.

Thanks in advance,

       Vincent