Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Timothy Brownawell schrieb:
>>>> (I'm trying to revive the out-of-band error handling from the last
>>>> summit in my spare time because I really want netsync-over-stdio
>>>> working now... maybe this rather small code part could go into your
>>>> branch as well? 
>> 
>> Not sure how small that would be. I seem to recall PipeCompatibleProbe
>> not liking to have both stdin/stdout and sockets at the same time (at
>> least on Windows), and the automate commands and stdio/remote_stdio
>> machinery aren't set up for forwarding stdin.
>
> They also have no concept of "interactivity" at all. My quick hack in
> this direction has been to simply disable password prompts via a global
> boolean variable in app_state. I then headed to adapt and use
> key_store::cache_decrypted_key to decrypt and cache a particular private
> key before its usage via another automate command, but gave up on this
> idea because the key_store (and therefor its cache) seems to be
> reinitialized after every (automate) command. 

I've been thinking we need a version of automate stdio that caches
information across commands, rather than reinitializing everything for
each command. In particular the database object and the current
workspace could be cached. That would significantly speed up queries
when preparing a commit; for example, a typical session would be:

cache session
inventory
get file 1 (for diff with changed version)
get file 2
...
close session
commit

So maybe we could cache a key as well.

Changing to a different workspace or database during a session would
have to be forbidden and detected.

Any automate command that currently builds a workspace object would
have to be changed to use the session cached workspace object. That
could be done incrementally.
-- 
-- Stephe