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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Timothy Brownawell wrote:
>> 
>> Automate commands get a special std::ostream to write to, while normal
>> commands use P() or std::cout. So while you could execute normal
>> commands, there's no way to capture any output.
>
> ...if we wouldn't rewrite all other commands to write to a special
> std::ostream just like automate does today, right? I've read something
> that it seems to be possible to swap the underlying std::ostream of
> std::cout with your own one: http://www.mr-edd.co.uk/?p=16.
>
> See, my main fear is that we eventually start to "duplicate" cli
> commands which read "remote_stdio", "remote_tags", "remote_whatever"...

We've already started that process, for automate versions of commands.
Let's continue that, rather than adding a third version of each
command. So if you want a remote version of a command, create the
automate version, and use that.

It would be interesting to require all commands to be automate
compatible, and then implement the command line interface as a layer
on top of the automate commands. The command line interface would just
translate the automate strings into more friendly format. Lots of
work, though.

> Ok, right, but the main point is: automate's output is for implementors
> only and therefor less likely subject to change or even to localize, so
> real "remote database functionalities" implemented like this feel like a
> hack.

What are the use cases for user use of remote database access? The
only one I've come across is 'ls branches', because I want to limit
the initial pull. After that, I'm happy with netsync.

-- 
-- Stephe