[ANN] bzr.webdav: a writable hhtp transport
John Arbash Meinel
john at arbash-meinel.com
Tue Aug 22 17:43:00 BST 2006
John Arbash Meinel wrote:
...
> 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.
>
> It also violates our layering, because Transport isn't supposed to know
> anything about the contents of the files it is moving around.
>
> 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. It may be necessary, especially
> if we want to support DAV and FTP servers that don't implement append.
> But it isn't trivial. Doing it nicely requires a lot of high-level
> information that Transport should not have.
>
Rather than having 'supports_append()' it might be better to allow
Transport.append() to raise an AppendNotSupported() execption. And the
calling code can handle it appropriately.
It isn't 100% better, but for FTP you don't know if APPE is supported
until you try it. So the first append() call probably needs to check,
and then can cache the value and always raise the exception for the
lifetime of the Transport.
It would be possible to do both, but then you get code that looks like:
succeeded = False
if t.supports_append():
try:
do the append thing
succeeded = True
except AppendNotSupported:
succeeded = False
if not succeeded:
do the non-append thing.
Basically, you kind of always need AppendNotSupported because of FTP, so
we need a reasonable way to do this.
Also, we have the problem that at the time we are doing append() we are
inside _KnitIndex or _KnitData. Which doesn't necessarily know that
there even exists another KnitVersionedFile object which already has the
content it cares about.
Which means we would need to handle append() failures at an even higher
level. Which means modifying the VersionedFile api with a
'join_with_append()' versus 'join_without_append()' sort of function calls.
Anyway, it is doable, but the 'supports_append' flag is one that needs
to get propagated from a low level Transport information, all the way up
into some really high-level functions that can actually implement things
in manners that don't require append.
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060822/0c19ac4b/attachment.pgp
More information about the bazaar
mailing list