A GIO transport

[Mattias Eriksson]

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.

Yes I thought that it was to small of a feature to be a standalone
plugin. So I'll look in to fixing the loading, tests and other issues. 

> 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.

I'll fix this.

>  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.

I just didn't find how to register a general gio+ handler, but I'll look
in to that.

> > 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?

Is it possible to customize the auth message to explain this to the user
in this case?

> >     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.

Sounds good.

> >     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.

Well actually I deleted them since they were just hanging, and the own
key handling explains the strange mounting behavior. So I'll try again
using some other transport, file urls may  be ok to test most things but
as you say it would be good to have something requiring auth.

> >     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'll look in to this.

> 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.

I just planed to remove them when I was done, but this way I can keep
them for future debuging. 


Thanks for all the comments... 

//Mattias