> The proper way to use new client message types (which is now > described > in the RFB spec) is to advertise a new pseudo-encoding for > that client > message type and wait for the server to send the > pseudo-encoding back to > the client. That lets the client know that it is safe to use the new > client message type. This is what I'm using for my shared > memory encoding. > > Otherwise, there's no way to write a client that works with the > "enhanced" server and a normal VNC server.
Ok, yeah that makes sense. So yeah basically we would need to add new server encodings for our client->server messages, and then you get the server to send dummy "ack" messages for each one to say "yes, I understand this message type"? > The mechanism I described above is what the current preferred method > is. If you want, we can bring the topic up with the VNC authors as > AFAIK I'm the only person with a reserved client message type. Of > course, I think using a pseudo-encoding is a perfectly > suitable way to > address this problem. Yeah the only problem I see with it is that I don't see how the server can dynamically *change* the set of client messages that it accepts? -- Ramesh
