Keeping bzrlib loaded (was Re: Will the output of "bzr status" change?)

[Matthieu Moy]

John A Meinel <john at arbash-meinel.com> writes:

> Matthieu Moy wrote:
>> Hi,
>> 
>> There have been a lot of discussion on this list about the output
>> format of "bzr status", whether it's good or not...
>
> We are currently discussing having some sort of mode where you will run
> a bzr process, such that you connect to it using stdin/stdout, and keep
> issuing commands into it, and it keeps replying to you.

Is this very different from your "bzr service"?

Actually, I think the approach of "bzr service" can be slightly
better, since the client can ideally be called exactly like bzr
itself, and still has the notion of process termination and exit
status. With a continuous process using stdin/stdout, I'd have to
set up a process filter to know when the action is terminated.

One other problem is parallelism. In Xtla, we often launch several
asynchronous processes in parallel (typical example : launch several
"baz missing" in parallel, since each process is latency-bound, that's
a real gain of time). I don't know how "bzr service" handles
parallelism (the real question is "how multi-thread safe is bzrlib?"),
but it could, whereas a stdin/stdout approach would imply
serialization.

> I'm surprised they don't support async, but I guess that is life. You
> still would likely get better efficiency by keeping bzrlib loaded in
> memory and reusing it somehow.

Sure, but I think calling Python from lisp and keeping bzrlib loaded
are two different problems, and the second can be solved, and should
be solved more generically.

I didn't try "bzr service" yet. Last time I've heard about it, it was
listening from any localhost users, which I consider is an
inacceptable security problem (I could use it at home, but I don't
want to encourrage other users to use it before the security problem
is fixed). However, I do believe this is the right approach to follow,
since it would solve the startup performance problem for /all/
front-ends using the command-line interface (including DVC-bzr,
user-defined shell scripts, ...) and bzr's command line itself.

-- 
Matthieu