On 7/13/11 3:49 AM, Pierre Ossman wrote: >> This is not only >> disruptive but possibly even violates the fundamental nature of the RFB >> protocol, > > What makes you say that? The protocol doesn't mention anything about > update rates, only that each update should represent a full screen > change. So having one client updating at 30 Hz and one at 10 Hz should > not be an issue. It's just that the second client will see the > aggregate of three changes (from the first's point of view).
"The update protocol is demand-driven by the client. That is, an update is only sent from the server to the client in response to an explicit request from the client." -- RFB Protocol Spec, p. 4. In other words, the protocol is specified as a "client pull" protocol, and technically we would be breaking that spec by making it server push. I'm OK with that. We just have to understand the ramifications for compatibility. I think it's easy to make the client support both approaches, but probably not the server. ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
