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

[Timothy Brownawell]

Stephen Leake wrote:
> Thomas Keller <address@hidden> writes:
>> Timothy Brownawell wrote:

>>> This also adds an "automate remote_stdio <address>" command to make
>>> use of these changes, and on the server side a
>>>    get_remote_automate_permitted(identity, command, options)
>>> hook which is checked for each automate command received and defaults
>>> to "deny everything".
>> Is the execution of the "l5:stdioe" and "l12:remote_stdioe" commands
>> over stdio / remote_stdio forbidden (this should be the case)? 
> 
> The documentation says the hook get_remote_automate_permitted returns
> false for everything by default. However, I don't see the default
> implementation anywhere; it's not in std_hooks.lua.

There is no default hook defined, and it's set so that this has the same
effect as having a hook that always returns false.

>> How are network errors handled, i.e. are these encoded properly in
>> stdio or do these come as out-of-band messages? 
> 
> I think it's out-of-band; see network/session_base.cc
> session_base::do_io. That uses P for netxx exceptions.

Yes, network errors result in a message on stderr and the process dying,
the same as they do for netsync.

>> (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.

>> monotone.texi states that "automate remote_stdio"
>> has a --quiet option to supress some of the netsync output - maybe
>> this could be fixed by that.) 
> 
> I don't see where --quiet is used.

It's a global option that turns off P() (and tickers. but those aren't
involved here).

>> How are network timeouts handled, i.e. do we automatically reconnect
>> an idled but broken remote_stdio connection? 
> 
> See netsync.cc call_server; it uses E for a timeout, so it just
> aborts.
> 
> In some applications, we want an automate session to tolerate long
> idle times; it's waiting for a user to request something. When
> connected remotely, I think it's ok to not tolerate that. Especially
> for an ssh: connection, which ties up the remote database exclusively.
> 
> If the application wants to tolerate long user times, it should be
> prepared to recreate the automate session on its own, rather than
> relying on keeping an idle one open.
> 
> This should be mentioned in the info manual.

This should be documented now.