Transport w/ extra tests

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>
>>>Do you have a specific list of desirable exceptions?
>
>
> Probably PermissionDenied, FileExists, ConnectionReset also make sense.
>

These have all been added. LocalTransport and HttpTransport have been
updated to use them. And the tests updated as such.

>
>>>Anything else? Perhaps a TransportTimeout of some sort. (I know
>>>effbot.org can give a timeout for a download taking to long, but that
>>>may not be the best place to do it)
>
>
>>>(and it is a little tricky to test Http, since you would
>>>have to have an http server. Unless we trick HttpTransport into also
>>>supporting file:// type urls.)
>
>
> Perhaps you can use SimpleHttpServer for your tests.  Oh, and since http
> does support PUT, maybe you should say "http PUT is not supported"
> instead of "http does not support put" :-)
>

Well, http PUT doesn't put files into the directory. You need webdav for
that. (In theory you could have file uploading over GET, but that would
only work for short files)

But I changed the error anyway.
Also, I did implement a SimpleHttpServer for testing HttpTransport, and
a readonly Transport test. The only problem is that you have to fork a
child process to run the server (since it has to at least run in a
separate thread). And then kill it when you are done.
And os.fork() doesn't exist on windows. Do we think threads are safer? I
could try and implement something using either os.spawn or subprocess,
but we still have the problem that os.kill doesn't exist on windows
either. (In the end we could create an HttpServer which would close when
a specific URL was requested).

>
>>>>It
>>>>would be fine with me to enforce 100% UTF-8 control files.  ElementTree
>>>>will auto-decode bytestrings, but will it leave unicode data alone?
>>>
>>>
>>>Actually, ElementTree automatically decodes/encodes into utf-8. But the
>>>other control files need to be handled specially. (Notice that reading
>>>inventory is done in binary form).
>
>
> That is my point.  If we auto-decode all control files, we'll be handing
> a unicode-producing file to ElementTree when we try to get inventory.  I
> don't know what ElementTree will do.  The docs don't say how it decodes
> data, so I'd assume it will decode a well-formed Windows-1252 XML file,
> as long as the file has an encoding declaration.  But if you're handing
> it unicode data, will it try to re-decode it?
>
> In terms of output, ElementTree defaults to ascii, but Martin's wrapper
> changes that to utf-8.

That's why those files were opened in non-decoded form. I agree the
'rb'/'r' isn't quite right, but that's what was used.

>
>
>>>If I get some time, I'll look into adding some new exception classes,
>>>and moving the encoding stuff higher up.

Both of these have been done.
My SftpTransport and RsyncTransport have not been updated yet, though.

>
>
> Cool.
>
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050719/08d36866/attachment.pgp