DarkWyrm wrote: > I agree with all that each of you have said. I would like to fill all > of you in on the whole mess so you can at least understand why things > are the way they are, seeing how I'm responsible for this one. *sigh* :-) We were at the beginning. We didn't know the exact requirements, we didn't know what we know today, we learn constantly. I too am a bit of shame of the current clipping code, but that was my first try and I didn't know all the intricacies. Same goes for the old window management stuff - it was _really_ messy, and that too was the first attempt. As Ingo or Stephan said in an email - you never get it right from the first time. > A while after Adi came on, he found that we needed to have some message > caching on the client side, so the whole PortLink vs Session thing came > about. Pahtz eventually resolved it by integrating both classes into > something which at least in concept would work well. Yup, in concept. I wonder what happens if I want to transfer a 10K region? That region will be transfered to app_server, but the buffer will remain at 10K ! That's a _bad_ thing as the buffer is too big for caching drawing commands and the GUI will be less responsive. It's enough that the initial buffer has 2K (R5's one is 1K), but 10K is already too much! > It's only been > since probably last summer that the server has been at a point where > stability in the BPortLink class has really been an issue - everything > else was so unstable that it was hard to notice. BPortLink as it is now, is just as instabile as BSession. The only good thing is that the messages are complete. > AFAICT, the message format is really what is at issue and the reason > for all the instability. There are a few determining factors for the > class: > > 1) Messages need to be able to be sent on a one-at-a-time basis > 2) Message caching needs to be possible to help with speed in handling > BView drawing messages by grouping calls to write_port() > 3) It shouldn't be possible to just write a random message to any of > the server's ports and crash or hang the server That's not easy doable with current format. > 4) Synchronous replies need to be possible As long as there are 2 ports there is no problem. 5) should we group mouse_moved messages that come from input_server? If yes, then we need to be able to read all messages present in port's queue. Current implementation does not allow this. bye, Adi.