A GIO transport

Mattias Eriksson snaggen at acc.umu.se
Mon May 3 19:03:21 BST 2010


I have pushed an updated version with the issues fixed to
lp:~snaggen/bzr/gio-transport

The test are only local at the moment (since I didn't get any server
supporting authentication to work). One test is still failing,
per_transport.TransportTests.test_put_file_unicode should raise an
UnicodeEncodingError according to the test. put_file in the gio
transport never reads the file but just passes it to the
ConnectedTransports _pump method (that uses osutils.pumpfile). So I
don't know the best way to fix this. Ideas?

//Mattias

mån 2010-05-03 klockan 10:16 +1000 skrev Martin Pool:
> On 2 May 2010 00:06, Mattias Eriksson <snaggen at acc.umu.se> wrote:
> > Hi,
> >
> > Here is a first attempt att creating a gio transport for bzr. The reason
> > I wrote this is that I'd lite to store a bzr repo on my Apple
> > TimeCapsule that only provides afp and smb file access. So by using gio
> > as a transport it should be possible to use all protocols supported by
> > the gnome gio library (currently ssh/sftp, ftp, dav, smb, obex I think),
> > but I have only tested it with smb and ssh. Note that this is not a
> > merge request since I think there are still some work to do.
> 
> That's a great feature, thanks for putting it up.
> 
> It's so small I would be ok with just merging it in when it's ready.
> We would want to make sure that it does not load gio unless it's
> needed, and that it copes if gio is not available including in tests,
> but we have plenty of infrastructure for doing this.
> 
> You have in the header "Copyright Mattias Eriksson, Canonical" which
> is a bit ambiguous; what I would suggest you do is put your name in as
> author and do the Canonical contributor agreement to assign copyright.
>  This is optional if you want it to just be a plugin.
> 
> Rather than listing all the protocols supported by gio in your
> transport registration it would eventually be nice to say that
> anything started with gio+ is supported and then we see if gio can
> actually handle the next part of the scheme.
> 
> > Some things I need help with:
> >     1. Authentication, currently this is handled with no interaction
> >        with the built in authentication mechanisms, since I do not know
> >        how that handles asking for domain for protocols that requires
> >        this (smb). I'm also thinking that i might be good to hook in to
> >        gnome-keyring if available (since the gio transport already
> >        depends on gio and gtk), does this sound like a good idea or
> >        just crazy?
> 
> I think looking at gnome-keyring with a soft dependency on bzr-gtk
> would be fine, but perhaps it's possible to do this purely through
> bzrlib's authentication interface.
> 
> Perhaps the simplest way to handle the domain is to just take the
> username as DOMAIN\USER?
> 
> >     2. This module should only be loaded if gio is available I think,
> >        how can this be done (or only if the url starts with gio+)? or
> >        is this how things work already?
> 
> I think your current code will be fine if you don't use a gio+ url,
> and then will give an error that gio is not present.  This is probably
> fine.
> 
> >     3. Tests, I can't seem to figure out how to create a working
> >        testsuite. I tried to base it on the sftp tests but the
> >        authentication doesn't work for some reason.
> 
> From memory the sftp tests use asymmetric keys and you might be having
> trouble getting the gio sftp client to see the private key.  Perhaps
> it would be easiest to test gio on top of http or even file urls,
> though I suppose we would also want to test authentication is hooked
> up properly.
> 
> Perhaps you can push up your failing tests for us to look at.
> 
> >     4. The mounting of the volume is done asynchronously, so I
> >        currently have a not to pretty loop waiting for this to be done.
> >        Is there some fancy way to do this in python?
> >
> > so what do you think?
> 
> I think what you have looks reasonable.  Perhaps you don't need the
> sleep() if gtk_main_iteration keeps its promise to sleep until events
> are available, but from memory it may actually spin?
> 
> I would show a message through ui_factory that you're waiting for the
> filesystem to mount.
> 
> > Also, I'm quite new to python so any feedback on codingstyle aso is also
> > welcome.
> 
> It looks pretty good.  Normally we wrap mutter statements in eg
> 
>   if 'gio' in debug.debug_flags: mutter()...
> 
> so they can be selectively turned on, except for those showing
> developer warnings.
> >
> > //Mattias
> >
> >
> 
> Thanks
> 





More information about the bazaar mailing list