RFC: TortoiseBzr strategies

[Mark Hammond]

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

Thanks,

Mark