> Sure, that would solve lots of the problems. OTOH it's a lot more > expansive, too. BMessages would need to be changed a lot, too, since > they currently can't be merged together for a simple port write. > Stephan proposed to use structs, just like the debug server does. > This > would lighten the problem as well, but wouldn't solve it as good as > BMessages would. I forgot to mention that we wouldn't change BMessage. Instead, we'd use that format for a something like an ServerMsg class which would be used only in the places where PortLink is currently used. As for the merging thing, I don't think it would be an issue from what I have in mind. A SeverMsgQueue could take a ServerMsg as an argument and directly copy the message's buffer to the queue's buffer, flushing when full. > > The original reason for PortLink was a low-overhead messaging > > class. > > The reason? All the Flatten() and Unflatten() calls had serious > > overhead. Be even acknowledged this and changed the format in Dano > > which used a flattened format to start at the expense of some extra > > space. If this were the case, we could use a format code just like > > we > > do now and the buffer would contain the message. A queueing class > > could > > be put together relatively quickly to group write_port calls for > > BView. > > Thoughts? > > A BMessage would still be substantially more expansive than > BPortLink. > I have no idea if the system is fast enough to make this difference > negligible. > But I don't think we should do this now - as Adi said, Be used even > something simpler than BPortLink. It really only gets to be > problematic > when we start sending messages over the network, where two clients > can > have different versions of libbe.so. IOW we would need to never > change > the size of any "code", but instead using new ones (or make the new > fields optional). > We own the code, so (apart from bugs), we only really need to care > about backwards compatibility. I have a feeling that the reason that Be even used BSession, caching aside, was because of performance constraints. Considering the number of problems it solves, I'd be willing to live with the size bloat if it weren't something like 10+ times larger than before. --DW