"DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx> wrote: > > 1) as I said, the input_server is not yet started by our > > app_server. > > This, for example, was the reason why I never got any input; I just > > didn't know that this part is missing from the app_server > Just simply hadn't been done yet. :) Shouldn't be difficult for the > initial start. As for restarting it when it's been killed, I'm not so > sure about that one. That's very simple: just let the input_server own the communication port. If it crashes, that port goes away, and you can then just (try to) start it again. > > 2) the input_server creates a new BPortLink (which is not that > > cheap > > after all) for every update message, instead of having a local copy > It shouldn't be, but IIRC Jason Vandermark wrote that code, so I > can't > say why it was done that way. I could fix that part, too, it's not that hard 8-) > > 6) the input_server should probably have separate "streams" for > > different devices, although I am not sure if the current > > architecture > > allows for this; the input_server should offer what it has, and the > > app_server should tell the it how to multiplex it into different > > streams (that way we could support more than one user with separate > > input devices, which would be nice in combination with dual head) > That paints an interesting picture. Question: would such a setup have > two cursors, then? That was my intention, yes. Surely, that doesn't have to be an R1 thing :-) > > 7) I can see no reason why LinkMsgReader/Sender are separate from > > BPortLink, at least aggregate them instead of doing just another > > pointer reference > I needed to subclass them in order to support sending and reading > messages sent over an area. If you have a better solution, I'd be > glad > to hear it. Actually, I don't understand this. There is no logic in BPortLink at all besides forwarding the requests to either LinkMsgSender or Reader (which should probably renamed Receiver to make them a pair). > > 8) if we had a slightly improved BMessage, it would be potentially > > faster for input_server communication as BPortLink - the > > input_server > > uses BMessages internally, and they often could just be forwarded, > > instead of, like with BPortLink need to be rebuild every time > > (right > > now, though, their speed should be similar, as the BMessage stuff > > is > > not that optimized) > Back when I first started working on the server, I thought we should > use BMessages all over, but was informed about the performance hit in > repeated flattening and unflattening. I'd love to have us migrate to > BMessages if we could go to the BMessage format used in Dano/Zeta for > R2. Why do you think should we inherit that performance hit? I mean we do now as Eric was a bit lazy, but there is no reason it stays that way for R1. But anyway, BPortLink is fine for most of the stuff for now; there is no reason to change all that now; input_server communication is a bit special as it internally already uses BMessages. > > 10) also, since it's me, I wanted to take the opportunity to > > remember > > you that we have a style guide to adhere to. Michael and Stephan > > seems to know about it at least :-) > Not that I've written any code lately, but we all can use a reminder > now and then. Thanks. :D Hehe :-) Bye, Axel.