It seems there are lots of ideas of how to improve the app_server communication. Since we seem to be deviating more and more from BSession, I would like to explain a bit how BSession in R5 works, and what its strengths are. 1. BSession has pre-allocated buffers For reading as well as writing, the session has a buffer which is created at app startup. This means that when data like an int32 is added, it's just copied into the buffer and the buffer position is increased. There is no overhead from allocation/re-allocation. So what if the buffer is full? Well we flush it. 2. BSession flushing BSession is flushed at several occasions. The first one is obvious, when the buffer is full it is flushed. Flushing means the data is sent through the port, and the buffer position is reset. A second occasion for flushing is when we send a command which expects a reply, like querying a view state. The third occasion is periodically, from the app loop. 3. BSession reading When we read from a BSession, just like writing, we actually read from the buffer. When we read at the end, the buffer position is resetted, and new data from the port is copied into the buffer. 4. BSession works with incomplete messages As I said, when the buffer is full, it is flushed. This could mean that we are in the middle of a message. However, this poses no problem. At the app_server side, we read from the session and start retrieving the data for the command. Since the command identifier is first, we can already jump in the switch statement. We can already read and convert the data which we manage to read from the session. Look at it as a webbrowser, a browser doesn't wait until it has the complete webpage with all the data before it starts rendering the page. It's a streaming protocol. 5. BSession doesn't know the size of fixed size commands Also this is no problem, as the protocol is defined, like a standard. If a message has the wrong size, this is an indication that there is a bug. While it is convenient to have a method to detect this during debugging, it is not needed in a release. 6. BSession is not secure About security. BSession is not used by application developers, it's purely a communication mechanism between libbe and app_server. Protecting it from malicious port messages is something which needs to be done at a port level, not at protocol level, as it is needed everywhere not just in this instance. I hope this shows at least a bit that BSession does make sense. It is one of the most lightweight possibilities, and some of its appearant weaknesses are in fact strengths which we lost by solving inexistent or weakly defined problems. -- Marc Flerackers