Protocol Changes (was: Zoom / Scaling in VNC)

[Brandon Ibach]

Quoting Jens Wagner <vnc "at" hexonet.de>:
> When using names, why not using a naming scheme like used in email headers?
> There would always be a officially supported set of message-type-names, and
> experimental/private names start with "X-"
> 
   Yes, this would be a good idea.  But only for a new version of the
protocol... :)

> Just to make it clear: this is not a framebuffer update (but it
> could be used as one), it is a seperate message type which is/can
> only be used when both client and server support it.  It is meant to
> be a universal extension-message. It has a length field, it even has
> got TWO. The message is always (8 + ext-type-len + ext-data-len)
> bytes long.  Every proxy just reads the first 8 bytes, computes
> (n=ext-type-len+ext-data-len) and read the last n bytes.
> The first dynamic-length-field, ext-type, is the type of the
> extension message.  This can be e.g. "resize-request\n",
> "zoom-request\n",  "X-Printer-Service\n" or anything else. The
> second dynamic-length-field, ext-data, contains the type dependent
> data, e.g. the requested size.  A proxy can support
> ExtensionMessages without to care about its content.
> 
   Yes, it is good that you put length fields in your protocol
extension (which, by definition, creates a new protocol).  But, my
point is that we could really use lengths on all messages, which would
require changing the entire protocol.

> I don't think so. Clients will just `abuse' the setEncodings-message to let the
> server know that they support extension messages. That has absolutely nothing to
> do with framebuffer updates. Older v3.3 servers don't recognise this encoding.
> So they will never send a ExtensionMessage, and the extensions of the clients
> will never get activated. Servers that recognise the hint will send an
> activation message to the client. Now the client can be sure that
> ExtensionMessage is supported by the server [and by the proxies between] and use
> it itself.
> 
> The version will remain "v3.3" - it is compatible with v3.3 both on client- and
> server-side.
> 
> There is no extra effort being needed when done my way.
> 
   Your method is really no easier than a new protocol version.  Our
scheme calls for using the version number feature, which already
exists in the protocol, to allow for a new, extended protocol to be
used, when supported by both client and server.  Your method calls for
'abusing' a current feature to accomplish a subset of the same
functionality.  Your "extension" is just a way to encapsulate a new
"sub-protocol" in the existing one.  Why not just use a new version of
the protocol?

-Brandon :)

---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------