[RFH] Rework Bazaar Explorer + QBzr to use separate process for bzr operations and main process only as GUI presenter

[Alexander Belchenko]

Gordon Tyler пишет:
> On 5/3/2011 3:55 PM, Alexander Belchenko wrote:
>> For all bzr operations, the most often used by explorer is getting
>> status of working tree, -- start new separate process for each bzr
>> location. That process works as server and can talk with any number
>> of clients via IPC mechanism (I'm thinking about using
>> cross-platform QLocalSocket/QLocalServer from PyQt4 if that matters).
> 
>> Using one process per bzr location is inspired by Google Chrome
>> architecture (as I understand it). This approach has several pros
>> and some cons. This process might fail/segfault/whatever without
>> affecting the GUI process. Therefore we need another global process
>> to watch worker processes and if needed restart the crashed ones. I
>> think it will be nice to adapt ideas from bzr-service plugin for
>> such watcher. Or maybe add that process to AutoRun as TBZR does
>> (does Ubuntu/Linux have some sort of autorun?).
> 
> Do you want to have these server processes shared by multiple bzr
> explorer and qbzr client processes? That does deviate from the Chrome
> model. Chrome has one parent process that manages the GUI and launches
> child processes for each host? that it communicates with. Each tab in
> each window is also a separate process. However, none of these persist
> past the lifetime of the parent process. When you close the last
> Chrome window, all Chrome processes die.
> 
> I'm very wary of daemon/background processes that do not have a well
> defined lifecycle.

That's a good question. Yes, I need server process for each active bzr
location to be shared between multiple qbzr / explorer process, so
only one bzr process working with one local or remote location. When
all client processes quit then server process should become inactive
(i.e. stop executing bzr operations) and die after some amount of time
(can't say yet how long). I would not kill server right after the last
client quits because it could be needed very soon by another fresh
client and having the server ready-to-use and warm means we can have
faster startup time for new-client-invoked-not-very-long-after. That's
in theory.

In practice anything can happens, some client processes can die
without notifying the server about disconnect, and any shit can
happen. So we will need to use some heartbeat signal between
interacting processes. But this inevitable will increase the
complexity of this approach, and I'm not positive.

Of course, in much simpler implementation server should just die when
last client quits.

But perhaps the most important point for me here anyway: server should
automatically become inactive after some amount of time when there is
no commands/requests from clients. Inactive means stop actively
crawling bzr tree for changes. Actually I don't want them to crawl the
locations at all, but instead use FileSystem watchers (like inotify,
PyQt4 has the handy and cross-platform one) over key bzr files to know
when something changed and need update of status cache. That means
when user run some operation in the console that bypass our server
process we anyway will be notified about need to refresh.

Also I seriously think about "cheating" here and update cache based on
the set of files used in the last bzr operation. I.e. after qcommit
the status cache can be immediately updated with the list of committed
files and status cache may think that all those files now "clean". In
the same time we start real bzr iter_changes() cycle to get the real
status of the tree. But until it finishes server already can send to
explorer new "calculated" state of the tree, and then send "real"
state of the tree when iter_changes() finishes.

That's why I need one server process per location and all operation
should go through it (or at least q-dialogs should notify server about
the changes they made) -- this is way for "cheating" and make explorer
"feels faster", in my opinion. Overall goal of my client-servers
madness is to improve the stability of explorer and make it feels
faster than command-line bzr.

Hope that makes sense.

(I was very impressed by one lightning talk at UDS-M Thursday or
Fridays Plenary given by the man I don't remember his name
unfortunately :-( about speed up the applications. Unfortunately when
he started to talk about caching and "cheating" in chrome and git his
5 minutes ran out, and I haven't chance to talk with him later. Does
anybody know who he is? I haven't found the video for those lightning
talks. Anybody?)

-- 
All the dude wanted was his rug back