Re: new console server code checked in

[Marcus Brinkmann]

On Tue, Jun 04, 2002 at 11:55:35PM -0400, Roland McGrath wrote:
> > It actually makes for a runnable program that does something visibly useful.
> 
> That's fantastic!  (And well beyond the norm for new Hurd features. ;-)

That's just because I have a running Hurd system to go along with :)
 
> 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. 

Good point, I will investigate this.

Autodetection might be hard, esp if I start to use the high bits for
attribute flags, unless of course it works he normal way of using a
preamble.

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

Extra RPCs are another thing I'd need to design :)  something which I would
like to avoid.  But maybe they are necessary or comfortable, I guess we will
find out.  I will try with a simple interface basedon what Nils suggested in
a first version, until we have more experience (and a lot of code on both
sides).  I am happy with defining this interface as internal for now, and we
can change it arbitrarily.  As long as no RPCs are involved, there are no
glibc (libhurduser) versioning issues either.
 
> > 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.

Mmh, I thought it would work over sockets, and would involve some sort of
communication protocol over that.  After all, you can do multi-attach etc.
But I never looked into it, so I really don't know.

Of course, also the experiences of the X and Berlin guys are relevant.

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

I am learning that now :)

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

Ok.

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

Actually, the separation into two different programs has helped me a lot to
overcome my inertia and make progress on the issue, also because it cleared
up my head about what belongs where.  It's dead clear what has to be put
into which of the two programs after you get a task boundary between them :)
So, I think this approach has made it easier for me to get the code base in
shape (like, compare vga-display.c - the old version, with display.c, the
new version).

Now, I am determined to carry it through, even if performance will not be
100% initially, and the interface will be slightly or completely wrong.
If I stumble upon hard problems, it won't be too late to make it a single
program (by replacing the file notification hooks with hooks into the
display driver elsewhere in the program), so I don't think much is lost by
trying.  Actually, if I factor out the code common to two console clients,
that boundary will make it very clear how the console client can be glued to
the console server if it is linked into a single program.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de