bzr-gedit Roadmap

[David Allouche]

On Mon, Apr 21, 2008 at 8:46 PM, Javier Derderian <javierder at gmail.com> wrote:
>
>
> On Sun, Apr 20, 2008 at 8:28 PM, Martin Pool <mbp at canonical.com> wrote:
> > Is gedit going to run bzrlib within its own process, or as a subprocess?
> >
>
> I'm doing a simple "import bzrlib" and using it, not executing "bzr
> *command*"
> for each command that's done. I don't know if that answer your question :)

That answers the question: gedit is going to run bzrlib within its own process.

You need to be aware of how it may affect the application's
responsiveness: bzrlib is an synchronous API, meaning that when it
takes a long time to complete a command, it prevents anything else
from running in the same thread.

So you need to either:
 A. Accept that when bzrlib is slow gedit will stop redrawing the
window and responding to user interaction
 B. Run bzrlib commands in threads. I am not aware of any existing
multithreaded user of bzrlib, so you may have to shake out a few bugs.
 C. Run bzr in a subprocess.

I do not think A would be acceptable.

B could be reasonably easy if you place the thread boundaries at the
places to minimize the need for synchronization. You might also need
to introduce a mutex to prevent multiple concurrent calls to bzrlib.
However it means that it would be difficult to interrupt a bzrlib
command that is taking too long for the user's taste.

C would be the most work, and add some overhead because data will have
to be serialized for transmission from the child process to the parent
process, but it would also be the most robust.

Choose carefully.