Jens, Const, Jonathan and others,
> > While changes to the RFB protocol could be reasonable, I think that
> > proposed changes should affect major version number of the protocol. I
> > believe the version should be "RFB 004.001\n". The reason is provided
> > in the original RFB 003.003 specification: all client/server
> > combinations supporting the same major version number of the protocol
> > should be compatible with each other. To achieve this, we should not
> > define any new protocol messages in 003.*, only new encodings could be
> > added to satisfy compatibility needs.
Compatibility is critical since any break requires that all
viewers and servers be improved to move the whole project
forward. Since no one organization has the resources to
actually update every single viewer and server implementation,
we must be careful to either:
1- make small protocol updates, which can be quickly rolled out to
the vast majority of the viewers and servers, or
2- keep our improvements compatible with the install base.
It would seem that one of the current problems is that there are
too many desired improvements and not enough people willing to
do the development work to get them rolled out to all of the
viewers and servers. One of our goals at Tridia is to foster a
growing set of features available in almost all of the viewers
and servers. This is a good reason for doing some work in
proxy servers.
In order to avoid any further splintering, my vote goes for
developing a small list of modifications that can be implemented
one at a time across the board.
>
> Implementations are not required to provide any new features.
> New color depths are very important for devices like the palm (4bit) and
> some mobile phones. I don't think that we'll need that much code, a
> single color conversation function should be sufficient for a server, if
> clean implemented.
> You're right, the value of rfb is simplicity, especially for the clients.
>
> > JW> 5.2.10 EnableZlibCompression
> >
> > JW> Feature string: "ServerZlib"
> >
> > JW> Asks the server to activate zlib compression for the complete
> > JW> server->client data stream.
> >
> > JW> --------------+-----------------+-------------------
> > JW> No. of bytes | Type [Value] | Description
> > JW> --------------+-----------------+-------------------
> > JW> 1 | CARD8 | message-type 1 | | compression-level
> > JW> --------------+-----------------+-------------------
> >
> > JW> message-type must be set to the value defined for "ServerZlib".
> > JW> compression-level is used to init zlib compression.
> >
> > Let me express my point of view on zlib compression. First of all,
> > it's not very good idea to compress the whole server->client stream:
> > compression works good when the data is statistically homogeneous. The
> > compression efficiency could degrade on server message headers.
>
> I must to say that I designed the proposal it in a way that makes it easy
> for upgrading current rfb software. If the client queries the feature on
> message-type number 10, it will exacly behave as Warrens zlib
> implementation.
Compressing the entire data stream will not improve the performance
noticeably. Compressing just the screen updates is sufficient. Also,
compressing the entire stream makes the work of proxy servers more
difficult. We were careful to include a length field in our zlib
implementation that allows a proxy server to easily manage a compressed
update. Since there is very interesting work going on with the proxy
servers, this is not an unimportant consideration.
>
> > And there is a way to implement zlib compression the way which do not
> > require any protocol changes. If zlib compression is made as an
> > encoding, it (1) could be done efficiently and (2) it will not break
> > compatibility. For implementation example you might want to look at
> > the TridiaVNC distribution. Unfortunately, I don't know who are
> > original authors of their zlib implementation, but zlib encoding is
> > implemented mostly "the right way" there. It breaks nothing: old
> > clients are fully compatible with new servers and new clients are
> > fully compatible with old servers (of course, zlib compression will be
> > activated only when both server and client support it).
>
> But didn't you say (on your homepage) that they destroy the tables
> between two updates and 'cause of this aren't that efficient as if the
> zlib stream were persistent?
This is something that we carefully avoided when doing TridiaVNC's
implementation of zlib compression.
>
> > By the way, we probably should have something like "the official list
> > of registered numbers" for new encodings (and maybe, for other
> > modifications). For example, it will be a good idea to assign a code
> > to zlib compression mentioned above. TridiaVNC uses 6 as the code for
> > their zlib compression; I think it could be a good idea to assign this
> > number and ``-encoding zlib'' vncviewer option to that encoding
> > ``officially''.
I agree completely with Const's recommendation on this.
>
> Maybe there should be possibility to request encoding numbers by name, as
> for features. That way a client could ask the server what encodings are
> supported and set the encoding numbers on the fly.
Requesting encodings by name will still require an official list.
Otherwise, viewer developer's will have little chance of getting
well known encodings in a reliable way.
-- Brian ---------------------------------------------------------------------------- TridiaVNC, the cross-platform, open source, remote control solution. http://www.TridiaVNC.com/ --------------------------------------------------------------------- To unsubscribe, send a message with the line: unsubscribe vnc-list to See also: -------------------------------------------------------------------------------------------------------------- TridiaVNC - http://www.tridiavnc.com/
This archive was generated by : Fri Aug 04 2000 - 09:10:22 EDT