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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Timothy Brownawell wrote:
>
>> This splits netsync.cc into multiple files, and splits the negotiation
>> and teardown out of the 'session' class. Then it adds 'automate_cmd'
>> as an alternative to 'anonymous_cmd'/'auth_cmd' so that network
>> clients can request either an automate connection or a netsync
>> connection.
>
> The split is definitely welcome, what I miss (and to be honest already
> missed before) is some chatter about the roles of the different classes
> and their inner workings. I know that monotone's source code is mostly
> documented, erm, "as is", so either I read and understand it or it is my
> problem, but still I see your refactoring as chance to improve the
> documentation of this crucial part of monotone.

I agree. For example, why do we need the notion of "wrapped session"?
It would seem deriving automate_session and netsync_session from
session would be simpler.

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

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

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

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

It would make sense to provide an option to set the timeout. If it is
possible to set it to "forever", then there should be a server hook
that forbids or allows that.

The whole point of a distributed cm system is to do as little as
possible over a network connection. I see user use of remote_stdio as
limited to minimal queries in preparation for setting up a local
database, like "what branches might I want to pull".

Using remote_stio to provide a web view of a mtn database makes sense,
but then the automate session should be opened, all the update info
pulled, and the session closed; I don't see a need for long idle
times.

> Are there more differences in general between commands executed in
> stdio and remote_stdio other than "interface_version returns the
> remote mtn interface_version" and "for actions which require a key
> the server's key is used" (ie. individual remote commits are not
> possible)?

Timeout is one.

All Lua hooks have the server value; that could be significant.

Other sessions might change the database while the automate session is
active.

There is no workspace on the server, so any command that requires a
workspace will fail.

-- 
-- Stephe