From: <li...@ho...> - 2001-02-14 00:32:14
|
> Okay, let's look at the basic design of this puppy. I don't > so much mean protocol details and the be or not be of security > (which I'd rather wait with until we have a prototype) but more > the general architecture. Security can be postponed a bit, but a bit of protocol design would be relevant to the architecture. The most important piece of architecture is how it fits in to the "client", as you have called it, the machine containing the netcon stub. The protocol is a big enough part of that to be an "architecture" issue. Your UA/server/client (although I'd like a different word than "client", maybe debugger-style "target"?) design makes sense, particularly if the netcon protocol will perform poorly over a long-haul link. > Although the current assumption is that Netcon Protocol is a UDP > protocol, it will provide a logical bidirectional stream capability. Once you're supporting a bidirectional stream, think hard about a stripped-down TCP. The only thing you might be able to do better with a hand-rolled one is pass state between boot loader stages. > I really want to define a specific terminal emulation for this protocol. > I definitely believe we do need more than a basic terminal, and having a > specific terminal emulation is key. The only logical such terminal is > some ANSI/DEC VT subset. Character set is yet another issue; I don't > think I have the guts to mandate UTF-8 over this stream. Ack! Pfft! Where did *this* idea come from? To put it more moderately, please explain why that is other than a Bad Idea. You said you want the server to do logging. ANSI cursor control seems like it would make that difficult, at least. We are working with minimal boot loaders and the like. Do you think they need significant termcap fanciness? (Are you trying to support BIOS config screens and the like?) I was thinking of something of the sophistication of Sun's serial console. The idea is to be able to debug booting and crashing problems in a headless machine in a machine room somewhere. If not, could we have a little discussion of intended applications? |