I mention scaling in the introduction of the document. Just not directly implemented into the draft as yet. I hope that server-side scaling, once implemented in the draft protocol, will allow more widespread adoption of this handy feature. Antialiasing could be done by the server, but I think that it might be better done on the client. However, I'll include orthagonality in the protocol if PalmVNC doesn't already include it.
It's up to the server and client to work with the platform's sound managers / drivers - the protocol is neutral about how you got the sound and what you do with it once you have it - it just provides the transport for a frequently requested feature. Obviously, if the client doesn't implement digital sound playback or recording (my Palm m100 for example has basic sound capabilities, similar to that of a Commodore 64), they can choose not to open the sound channel. The client tells the server about its tile cache during "discovery" using the configuration channel (the only channel that must exist). See section 9 of the current draft. When things change, like display resolution, or the keyboard disappears (USB land), the configuration channel can apply that change on the fly. For the extremely thin clients, the minimum functionality for a 4.x client is actually less than a 3.x client as you can negotiate not to take all but one channel (the configuration channel). Indeed, you could choose to implement just one tile decoder, and it should still work as long as the server has that encoder. This more than offsets the possibly increased complexity of the required minimum authentication (SRP). I'll note now that SRP can be slow on really slow platforms. A 16 MHz Palm will probably take up to 2 seconds to do the math required for a single authentication. Extensible channels are possible on top of the default ones, thus preventing incompatible protocols. Companies like Tridia can implement Tridia specific channels, but still allow non-Tridia clients to connect or vice versa. A client can open (or not open) as many channels as the server supports. Thanks for the feedback. Andrew ----- Original Message ----- From: "Wayne Throop" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, January 14, 2002 6:21 PM Subject: Re: RFB Protocol > No scaling? > Are there implementations for sound on linux, unix, and windows? > > I hope that the client is able to tell the server the size of > the tile cache, so that "not in cache" replies are kept to a minimum. > > I also hope that a client can remain very, very thin, > and ignore things like fonts, windows, strings, and other new > high-level constructs, and just bang out the pixels. > > And wrt a client remaining thin, scaling as a server-side thing, > and a way to get server-side downscaling combined (with antialiasing) > combined with client-side upscaling as a compression method... --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
