Re: doing more clientside processing – big catch here, Javascript. Doing physics processing in Javascript strikes me as not quite feasible — I think you realistically with O3D will be trimming most of the realtime interactive stuff away and ‘live with’ a 200-400ms latency between action and reaction.

1 – Polling is not as expensive as you’d think, just make sure each individual poll sticks around for a while. I’m fond of sending a POST every few seconds (if there isn’t already one pending) and then having the httpd sit around keeping the socket open for about 10 seconds until an event comes in. In-between polls, events are queued up.

This is fairly similar to how EQG in SL already functions I believe and i’ve tested it quite a bit for tunnelling purposes. It also works wonderfully on google app engine contrary to popular belief, and can be used to simulate background threads (I have a cool little system that serialises the full function closure between each request and stores it).

2 – You can offload some of the processing to the clientside and thus reduce network communication. Physics can be done very nicely like this, just resync every now and then. Security issues need to be taken into account of course, but in a worst case scenario a client may think it’s at location A while it’s really in location B – if done right it can’t actually manipulate location A or even see what content is there.

That being said – this isnt being pushed as a next gen protocol. The reason being there are better ways to do that – eg, MXP is a lot more interesting as a full VW protocol.

I was not aware google have a protobuf JS implementation – since I have not written the serialiser yet, this actually may be a good target.

The reason I suggested JSON was that it is very simple to parse and is widely used within the JS space.