Protocol Changes (was: Zoom / Scaling in VNC)

[Jonathan Morton]

>> And what's to prevent a new version of the protocol creating an
>> alternative update format that could be supported by a special case
>> that doesn't want to specify a length?
>>    As I said, there are issues both ways in including a length on
>> every message.  More important is a modification to the basic protocol
>> that will allow for the flexibility to have the choices.
>
>Some servers could have a feature "sendFrameBufferUpdateLength" that's
>initially off.
>The clients could turn it on then.
>IMHO all the other messages have a fixed length or they have simple length
>fields.

I'm personally in favour of a new protocol version.  It'll be a bit of work
to implement now, but it'll make it much easier to add more features in a
'clean' way in the future.  Say someone decides SSH isn't good enough, and
wants to use the PGP variant instead?  With an extended v3.x protocol we'd
be bickering over it for weeks on end till we finally get it sorted (as we
are now, discussing a simple length field!  Gawd!).  With a v4.x protocol
which supported human-readable strings as feature descriptors, someone
could simply stick the algorithm in, get it working, then show us the
results so we could easily port it to other servers and clients.  I draw
readers' attention to the old proverb: "a stitch in time saves nine"...


>>  Your
>> extension idea is just a much a new protocol as my total redesign, and
>> both are equally capable of maintaining compatibility with existing
>> implementations.
>
>So what about a list of new *optional* features?
>- resize
>- scale ( optional with antialiasing )
>- packedpixels( 2 x 4 bit_per_pixel into 1 byte )
>- zlibCompression
>- jpegEncoding
>- pngEncoding
>- sendFramebufferUpdateLength
>- ???

These are all useful things which have been asked for, and which would be
easy to implement under a new protocol version.  Admittedly, quite a few of
these would be supportable under a v3.x protocol as well with little
effort, but definitely not all.  I do have to point out that getting a
server to figure out which parts of the screen can be sent by a lossy
method such as JPEG may not be trivial...

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi "at" cyberspace.org  (not for attachments)
uni-mail: j.d.morton "at" lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.
--------------------------------------------------------------
Contributing to the VNC Project - http://www.uk.research.att.com/vnc/
Macintosh VNCserver v3.3.2 beta2.2 now posted at:
	http://chromatix.autistics.org/vnc/



---------------------------------------------------------------------
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
---------------------------------------------------------------------