tchize wrote: >> 5) To convey some of these changes to the client, a new protocol command is >> needed. But no reason to write that until we have data to actually send to >> it. >> > > > I'll opt for a complete rework of whole client/server protocol in a branch. > This way we can easily tweak new protocol for performance and not take > care of old protocol compatibility. Backward compatibility could come > afterwards when new protocol is mature enough. The problem, as mentioned in layering thread, is that some of these changes basically necessitate some mechanism for backward compatiblity. Basically, right now, the server stores 3 layers of information in the mapcells. I don't want to have to have those as well as all the new layers - I'd want those old layers to go away - this means some mechanism to pull the right data to display. As far as new protocol, I'd actually argue that there is less reason to branch that than making a change to an existing protocol. After all, we could pretty easily put something in at the top of socket/request.c which will basically have it refuse to serve the new protocol (by refusing setup command) unless uncommented - if someone is savy enough to mess with that, they can live with the consequences. I do note that I wrote up a 'map2' protocol proposal a while back and it does sit in the doc/Developer/protocol file as the proposal. I think tha should cover everything, but in that one, I only did 8 image layers (including smoothing), which wouldn't cover the proposal I just sent out.