> 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
