Re: new console server code checked in

[Roland McGrath]

> It actually makes for a runnable program that does something visibly useful.

That's fantastic!  (And well beyond the norm for new Hurd features. ;-)

> 2. The whole display interface issue, including asynchronous notifications. 
> I have some ideas for this obviously.  Maybe the first versions will be
> ugly, I hope that nobody expects us to not break the interfaces here in the
> beginning. ;)  It seems that with UCS-4 characters, we automatically get the
> joy of endian issues, so I will have to convert the data to network byte
> order somewhere.  This is not done yet.

It just seems like the interface is wrongheaded if it winds up doing byte
order conversions back and forth on the same machine.  I don't really
understand iconv, but it looks to me like UTF-32BE and UTF-32LE are
recognized charset names as well as UTF-32, and there is also some sort of
byte-order self-identification thing in there.  I think the byte order
issue can be dealt with in some better way than converting words to net order.

> For example, cursor position.  Either we will have to add a header in front
> of the screen matrix, which contains
> 
> Cursor X position
> Cursor Y position
> Cursor Status (very visible, normal, invisible)
> 
> Or we do this via request and notification messages, but then we need some
> extra RPCs.

Extra RPCs can be ok.  It could also be another mmap'd virtual file of
control structures rather than overloading the display file.

> Maybe I should look at how screen does it.

I'm not sure what you mean.  If you are still talking about the
asynchronous update issue, screen is just one program maintaining all the
state and driving everything from when its select/read wakes up and feeds
its terminal emulation engine.  I don't see how anything there is relevant
to your distributed design.

>From the start, I've thought your RPC-oriented many-translators plan was
the ambitious and more difficult route for the first pass implementation.
There are lots of ways for RPC or shared memory interfaces to be.  We can
only speculate about what kinds of interfaces we want until we have
substantial bodies of code on both sides of each interface boundary.  If
you just stuff multiple parts of the puzzle into one program with ad hoc
modular interfaces (a la term's backends), or marginally codified ones a la
libstore, you can implement and really use several modules and make them
tolerably efficient before trying to figure out what interface tradeoffs
to worry about.