RFC: TortoiseBzr strategies

John Arbash Meinel john at arbash-meinel.com
Sun Mar 30 11:33:52 BST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins 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.
|
| 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.
|
| -Rob

I think that having a C++ shim for the Shell portion, which uses some form of
RPC to a more involved process is a good way to go.

I think having an XML process is okay, not my personal favorite, but as someone
else is going to be implementing it...

I do think it would be nice to have something that multiple processes could use.
So that Eclipse could talk to the same Daemon as TortoiseBZR.

It certainly would be useful to have as much be cross platform as possible.


My personal favorite GUI toolkit is WxPython, since it uses native widgets and
works on Windows, Mac, and Linux without worrying about licensing. Qt is a great
toolkit, I just needed something for a minor commercial app and didn't have the
$$ to spend on a QT license, oh and before 4.0 they didn't have a GPL Windows
release either.

As QT has now released a GPL version it might be something to look closer at.

I think the team has done well with GTK (the best part for me is that you can
hook it up to the unittest suite, and test widgets without displaying them.)
However, it is poorly supported on Mac, and uses its own widgets. Some feel that
is a feature, personally I prefer the app to look like a native app everywhere.


For separation of concerns, it seems like the App which serves up directory
information would be separate from the one which displays gui widgets, but it
wouldn't have to be. (By doing so, though, you can write multiple gui widget
aps, and not step on any toes, etc.)

Personally, I would like to see as much as possible done in the rich python
object model that we already have, but as we do need to talk to other processes,
it cannot be the universal component. (And I guess XML is fine at that point.)


As for the name... I would stick with TortoiseBZR (or Bzr, or Bazaar), just
because of the instant name recognition for people used to other projects.

Oh, and the other nice thing about a lightweight shim, is that hopefully all the
other processes can be re-used for NautilusBzr, and anything we want to do for a
GUI on Mac.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH72yQJdeBCYSNAAMRAuBIAKCcOIYs8XoTnV2TP3qRL59OG7bbkQCg07Xj
+n/26cochwgcqN2QhWgnbvQ=
=byUR
-----END PGP SIGNATURE-----



More information about the bazaar mailing list