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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
