Revision: 3796
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3796&view=rev
Author: ossman_
Date: 2009-04-30 12:10:18 +0000 (Thu, 30 Apr 2009)
Log Message:
-----------
Prepare document for extensions
The original document is closely tied to RealVNC's implementation in
many aspects. Try to make the important bits more general and clear.
Signed-off-by: Pierre Ossman <oss...@cendio.se>
Signed-off-by: Daniel P Berrange <d...@berrange.com>
Modified Paths:
--------------
rfbproto/rfbproto.rst
Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst 2009-04-30 11:41:03 UTC (rev 3795)
+++ rfbproto/rfbproto.rst 2009-04-30 12:10:18 UTC (rev 3796)
@@ -106,12 +106,6 @@
the pixel data. The data itself then follows using the specified
encoding.
-The encoding types defined at present are *Raw*, *CopyRect*, *RRE*,
-*Hextile* and *ZRLE*. In practice we normally use only the *ZRLE*,
-*Hextile* and *CopyRect* encodings since they provide the best
-compression for typical desktops. See `Encodings`_ for a description of
-each of the encodings.
-
Protocol Extensions
===================
@@ -143,16 +137,15 @@
to be anything like the RFB protocol.
**Under no circumstances should you use a different protocol version
-number**. Protocol versions are defined by the maintainers of the RFB
-protocol, RealVNC Ltd. If you use a different protocol version number
-then you are not RFB / VNC compatible. To ensure that you stay
-compatible with the RFB protocol it is important that you contact
-RealVNC Ltd to make sure that your encoding types and security types do
-not clash. Please see the RealVNC website at http://www.realvnc.com for
-details of how to contact us; sending a message to the VNC mailing list
-is the best way to get in touch and let the rest of the VNC community
-know.
+number**. If you use a different protocol version number then you are
+not RFB / VNC compatible.
+All three mechanisms for extensions are handled by RealVNC Ltd. To
+ensure that you stay compatible with the RFB protocol it is important
+that you contact RealVNC Ltd to make sure that your encoding types and
+security types do not clash. Please see the RealVNC website at
+http://www.realvnc.com for details of how to contact them.
+
Protocol Messages
=================
@@ -482,7 +475,7 @@
Client to Server Messages
+++++++++++++++++++++++++
-The client to server message types defined in this document are:
+The client to server message types that all servers must support are:
=========== ===========================================================
Number Name
@@ -495,7 +488,7 @@
6 ClientCutText
=========== ===========================================================
-Other registered message types are:
+Optional message types are:
=========== ===========================================================
Number Name
@@ -508,7 +501,7 @@
250 Colin Dean xvp
=========== ===========================================================
-Note that before sending a message not defined in this document a
+Note that before sending a message with an optional message type a
client must have determined that the server supports the relevant
extension by receiving some extension-specific confirmation from the
server.
@@ -780,7 +773,7 @@
Server to Client Messages
+++++++++++++++++++++++++
-The server to client message types defined in this document are:
+The server to client message types that all clients must support are:
=========== ===========================================================
Number Name
@@ -791,7 +784,7 @@
3 ServerCutText
=========== ===========================================================
-Other registered message types are:
+Optional message types are:
=========== ===========================================================
Number Name
@@ -803,7 +796,7 @@
250 Colin Dean xvp
=========== ===========================================================
-Note that before sending a message not defined in this document a
+Note that before sending a message with an optional message type a
server must have determined that the client supports the relevant
extension by receiving some extension-specific confirmation from the
client; usually a request for a given pseudo-encoding.
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Tigervnc-commits mailing list
Tigervnc-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-commits
