RFC: TortoiseBzr strategies

[Robert Collins]

On Fri, 2008-03-28 at 11:54 +1100, Mark Hammond wrote:
> > Hi, at the london sprint the integration team has proposed the
> > following:
> > 
> >  - a local xml-rpc server which can be used as a stateful FFI to bzr
> >  - a new subcommand space for xml variants of all the commands needed
> > for external integration.
> 
> Yes, Ian pointed me at that discussion and I should have made explicit
> reference to it.  It may be that the requirement for the shell extensions
> are fairly small, given that much of the work is done in the external GUI
> application.  Specifically, it is likely the shell's requirements will be
> restricted to the local state of files and folders.  Also, if we optimize
> the interface towards the shell extension's requirements, the C++ code can
> be kept fairly thin.  In other words, I'm slightly concerned an xml-rpc
> server exposing a large API may be overkill for these specific requirements.
> This will become clearer as design work proceeds though.

So, the shell extension just needs:
 - get the right overlay for files
 - update overlays automatically as file alterations occur on the system
 - offer the right menu options for right-click events
 - know how to start the real gui for more complex things

The gui will benefit I think from being able to share the cache with the
shell extension. This will prevent doing a new bzr scan when the gui
starts, and may well ameliorate potential locking issues.

> > I would suggest the overlay be C++, it have a global cache process,
> > which could be .NET/python/C++ {you choose - balance memory usage over
> > time vs development speed etc etc}. Said cache is probably a
> > serialisation point, or needs to be multithreaded. I would expect that
> > users would not expect unrelated trees to block each other - so say
> > multithreaded. And this cache would also act as a proxy to the xml-rpc
> > servers being used to operate on various bzr trees.
> 
> Are you suggesting this xmlrpc server could be used by the shell, and also
> by the GUI application spawned by the shell?

Yes

>   This would mean the GUI could
> avoid using bzrlib entirely?  While I see the attraction to .NET folk, for
> example, what benefits are there beyond a shared cache for a Python-based
> stand-alone GUI to need such a server?

Don't knock the benefits of a shared cache :). But yeah, I would write
the gui itself in python with bzrlib very happily.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080328/c3e040a4/attachment.pgp