[PATCH 1 of 5 RFC] serve: add --cmdserver option to communicate with hg over a pipe

[Matt Mackall]

On Sat, 2011-06-04 at 01:01 +0300, Idan Kamara wrote:
> On Sat, Jun 4, 2011 at 12:16 AM, Matt Mackall <mpm at selenic.com> wrote:
> 
> > On Fri, 2011-06-03 at 23:04 +0300, Idan Kamara wrote:
> > > # HG changeset patch
> > > # User Idan Kamara <idankk86 at gmail.com>
> > > # Date 1307111261 -10800
> > > # Node ID 5b9901ab0f4c60450ecd5c112fd937493a043667
> > > # Parent  a67e866f46f9919a963afb4e4f1bb4a2c56a3c42
> > > serve: add --cmdserver option to communicate with hg over a pipe
> >
> > > +            sys.stderr = channeledoutput(sys.stderr, sys.stdout, 'e')
> > > +            sys.stdout = channeledoutput(sys.stdout, sys.stdout, 'o')
> > > +            self.fin = sys.stdin
> > > +            self.fout = sys.stdout
> >
> > What happens when a command like 'hg import -' wants to consume all of
> > stdin?

> I'm guessing we'd like the protocol to somehow support 'interactive'
> commands such as this.

We'll probably eventually want to support 'real' interactive commands
like merge and be able to channel prompts to GUIs.

But this particular example is tricky because it's about receiving bulk
data from the client.

Maybe we want channels in both directions. Then we can eventually have:

send:
command channel
bulk input channel
prompt reply channel

receive:
output channel
error channel
progress channel
prompt channel

Then library clients can attach themselves to callbacks on the prompt
and progress channels.

Thinking even further ahead, once we have callbacks, we can also have a
channel for implementing hooks on the client side. This gets tricky
because it will want to do commands inside commands..

-- 
Mathematics is the supreme nostalgia of our time.