Re: [rfbproto] [PATCH] Describe the xvp extension
Hi Colin! Den 2009-05-25 20:52 skrev Colin Dean: > Peter asked me to add details of the xvp extension, so here they are ... > > Colin So I did. Thanks very much for this contribution! Some nit-picks below inline though. Cheers, Peter > Describe the xvp pseudo-encoding and xvp message types > > The xvp extension allows clients to perform shutdown, reboot and reset > operations on virtual machines hosted on Citrix XenServer, via the Xen > VNC Proxy server, xvp. > > Signed-off-by: Colin Dean > --- > > Index: rfbproto.rst > === > --- rfbproto.rst (revision 3809) > +++ rfbproto.rst (working copy) > @@ -509,7 +509,7 @@ > 253 `gii (General Input Interface) Client Message`_ > 252 tight > 251 Pierre Ossman SetDesktopSize > -250 Colin Dean xvp > +250 `xvp (Xen VNC Proxy) Client Message`_ I regret spelling out the gii abbreviation in all headings, can we just have xvp Client Message", "xvp Server Message" and "xvp Pseudo-encoding" and then spell it out in one place please? I'll prepare a patch to the same effect for gii. > === === > > Note that before sending a message with an optional message type a > @@ -1043,6 +1043,27 @@ > > The event reports *count* valuators starting with *first*. > > +xvp (Xen VNC Proxy) Client Message > +-- > + > +A client sends this message to request a clean shutdown, clean reboot or > +abrupt reset of a Citrix Xenserver virtual machine it is connected to > +via the Xen VNC Proxy server, xvp. > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === > + > +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, > +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already > +established that the server supports this extension, by requesting the > +`xvp (Xen VNC Proxy) Pseudo-encoding`. Forgotten underscore just before the ending dot. > + > Server to Client Messages > + > > @@ -1066,7 +1087,7 @@ > 254, 127VMWare > 253 `gii (General Input Interface) Server Message`_ > 252 tight > -250 Colin Dean xvp > +250 `xvp (Xen VNC Proxy) Server Message`_ > === === > > Note that before sending a message with an optional message type a > @@ -1208,6 +1229,32 @@ > communications. A *device-origin* of zero indicates device creation > failure. > > +xvp (Xen VNC Proxy) Server Message > +-- > + > +This message is sent by the Xen VNC Proxy server, xvp. > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === > + > +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - > +XVP_INIT. > + > +A server which supports the *xvp* extension declares this by sending a > +message with an XVP_INIT *xvp-message-code* if it receives a request > +from the client to use the `xvp (Xen VNC Proxy) Pseudo-encoding`. Forgotten underscore just before the ending dot. > + > +A server which subsequently receives an `xvp (Xen VNC Proxy) Client > +Message` requesting an operation which it is unable to perform, informs Forgotten underscore again. > +the client of this by sending a message with an XVP_FAIL > +*xvp-message-code*. > + > Encodings > + > > @@ -1227,6 +1274,7 @@ > -239`Cursor Pseudo-encoding`_ > -223`DesktopSize Pseudo-encoding`_ > -305`gii (General Input Interface) Pseudo-encoding`_ > +-309`xvp (Xen VNC Proxy) Pseudo-encoding`_ > === === > > Other registered encodings are: > @@ -1245,7 +1293,6 @@ > -306popa > -307Peter Astrand DesktopName > -308Pierre Ossman ExtendedDesktopSize > --309Colin D
Re: [rfbproto] [PATCH] Describe the xvp extension
Second attempt attached, with corrections as suggested by Peter. Colin Describe the xvp pseudo-encoding and xvp message types The xvp extension allows clients to perform shutdown, reboot and reset operations on virtual machines hosted on Citrix XenServer, via the Xen VNC Proxy server, xvp. Signed-off-by: Colin Dean --- Index: rfbproto.rst === --- rfbproto.rst (revision 3809) +++ rfbproto.rst (working copy) @@ -509,7 +509,7 @@ 253 `gii (General Input Interface) Client Message`_ 252 tight 251 Pierre Ossman SetDesktopSize -250 Colin Dean xvp +250 `xvp Client Message`_ === === Note that before sending a message with an optional message type a @@ -1043,6 +1043,27 @@ The event reports *count* valuators starting with *first*. +xvp Client Message +-- + +A client sends this message to request a clean shutdown, clean reboot or +abrupt reset of a Citrix Xenserver virtual machine it is connected to +via the Xen VNC Proxy server, xvp. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already +established that the server supports this extension, by requesting the +`xvp Pseudo-encoding`_. + Server to Client Messages + @@ -1066,7 +1087,7 @@ 254, 127VMWare 253 `gii (General Input Interface) Server Message`_ 252 tight -250 Colin Dean xvp +250 `xvp Server Message`_ === === Note that before sending a message with an optional message type a @@ -1208,6 +1229,31 @@ communications. A *device-origin* of zero indicates device creation failure. +xvp Server Message +-- + +This message is sent by the Xen VNC Proxy server, xvp. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - +XVP_INIT. + +A server which supports the *xvp* extension declares this by sending a +message with an XVP_INIT *xvp-message-code* if it receives a request +from the client to use the `xvp Pseudo-encoding`_. + +A server which subsequently receives an `xvp Client Message`_ requesting +an operation which it is unable to perform, informs the client of this +by sending a message with an XVP_FAIL *xvp-message-code*. + Encodings + @@ -1227,6 +1273,7 @@ -239`Cursor Pseudo-encoding`_ -223`DesktopSize Pseudo-encoding`_ -305`gii (General Input Interface) Pseudo-encoding`_ +-309`xvp Pseudo-encoding`_ === === Other registered encodings are: @@ -1245,7 +1292,6 @@ -306popa -307Peter Astrand DesktopName -308Pierre Ossman ExtendedDesktopSize --309Colin Dean xvp 0x574d5600 to 0x574d56ffVMWare === === @@ -1759,3 +1805,18 @@ where the standard input model is insufficient. It supports relative mouse movements, mouses with more than 8 buttons and mouses with more than three axes. It even supports joysticks and gamepads. + +xvp Pseudo-encoding +--- + +A client which requests the *xvp* pseudo-encoding is declaring that it +is capable sending *xvp* client-to-server messages and accepting *xvp* +server-to-client messages. The server declares that it supports *xvp* by +replying with an *xvp* server-to-client message with an +*xvp-message-code* of *XVP_INIT*. + +Requesting the *xvp* pseudo-encoding is the first step when a client +wants to use the *xvp* extension to the RFB protocol. This allows +clients to perform administrative operations (shutdown, reboot and +reset) on
Re: [rfbproto] [PATCH] Describe the xvp extension
I think perhaps it might be desirable to change the description to avoid direct reference to Citrix XenServer / XVP in the docs. Instead say that the XVP extension allows for lifecycle control of a virtual machine associated with the VNC server. Then refer to XVP / XenServer as the primary / reference implementation of the extension. The reason I'm suggesting, is that I'm inclined to try adding this VNC extension to QEMU/KVM's VNC server too - this would in fact also allow Xen to be rebooted/shutdown/etc without talking to XenServer. Regards, Daniel On Wed, May 27, 2009 at 09:10:51AM +0100, Colin Dean wrote: > Second attempt attached, with corrections as suggested by Peter. > > Colin > Describe the xvp pseudo-encoding and xvp message types > > The xvp extension allows clients to perform shutdown, reboot and reset > operations on virtual machines hosted on Citrix XenServer, via the Xen > VNC Proxy server, xvp. > > Signed-off-by: Colin Dean > --- > > Index: rfbproto.rst > === > --- rfbproto.rst (revision 3809) > +++ rfbproto.rst (working copy) > @@ -509,7 +509,7 @@ > 253 `gii (General Input Interface) Client Message`_ > 252 tight > 251 Pierre Ossman SetDesktopSize > -250 Colin Dean xvp > +250 `xvp Client Message`_ > === === > > Note that before sending a message with an optional message type a > @@ -1043,6 +1043,27 @@ > > The event reports *count* valuators starting with *first*. > > +xvp Client Message > +-- > + > +A client sends this message to request a clean shutdown, clean reboot or > +abrupt reset of a Citrix Xenserver virtual machine it is connected to > +via the Xen VNC Proxy server, xvp. > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === > + > +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, > +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already > +established that the server supports this extension, by requesting the > +`xvp Pseudo-encoding`_. > + > Server to Client Messages > + > > @@ -1066,7 +1087,7 @@ > 254, 127VMWare > 253 `gii (General Input Interface) Server Message`_ > 252 tight > -250 Colin Dean xvp > +250 `xvp Server Message`_ > === === > > Note that before sending a message with an optional message type a > @@ -1208,6 +1229,31 @@ > communications. A *device-origin* of zero indicates device creation > failure. > > +xvp Server Message > +-- > + > +This message is sent by the Xen VNC Proxy server, xvp. > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === > + > +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - > +XVP_INIT. > + > +A server which supports the *xvp* extension declares this by sending a > +message with an XVP_INIT *xvp-message-code* if it receives a request > +from the client to use the `xvp Pseudo-encoding`_. > + > +A server which subsequently receives an `xvp Client Message`_ requesting > +an operation which it is unable to perform, informs the client of this > +by sending a message with an XVP_FAIL *xvp-message-code*. > + > Encodings > + > > @@ -1227,6 +1273,7 @@ > -239`Cursor Pseudo-encoding`_ > -223`DesktopSize Pseudo-encoding`_ > -305`gii (General Input Interface) Pseudo-encoding`_ > +-309`xvp Pseudo-encoding`_ > === === > > Other registered encodings are: > @@ -1245,7 +1292,6 @@ > -306popa > -307Peter Astrand DesktopName > -308Pierre Ossman ExtendedDesktopSize > --309Colin Dean xvp > 0x574d5600 to 0x574d56ffVMWare > =
Re: [rfbproto] [PATCH] Describe the xvp extension
Hi Daniel, > I think perhaps it might be desirable to change the description > to avoid direct reference to Citrix XenServer / XVP in the docs. > Instead say that the XVP extension allows for lifecycle control > of a virtual machine associated with the VNC server. Then refer > to XVP / XenServer as the primary / reference implementation of > the extension. > > The reason I'm suggesting, is that I'm inclined to try adding > this VNC extension to QEMU/KVM's VNC server too - this would > in fact also allow Xen to be rebooted/shutdown/etc without > talking to XenServer. It would be really good if QEMU/KVM's VNC server supported this. Can we agree on some naming, and then I'll submit a new patch. How about using "Xen VM control pseudo-encoding", "Xen VM control client message" and "Xen VM control server message"? Colin -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, May 27, 2009 at 10:18:46AM +0100, Colin Dean wrote: > Hi Daniel, > >> I think perhaps it might be desirable to change the description >> to avoid direct reference to Citrix XenServer / XVP in the docs. >> Instead say that the XVP extension allows for lifecycle control >> of a virtual machine associated with the VNC server. Then refer >> to XVP / XenServer as the primary / reference implementation of >> the extension. >> >> The reason I'm suggesting, is that I'm inclined to try adding >> this VNC extension to QEMU/KVM's VNC server too - this would >> in fact also allow Xen to be rebooted/shutdown/etc without >> talking to XenServer. > > It would be really good if QEMU/KVM's VNC server supported this. > Can we agree on some naming, and then I'll submit a new patch. > > How about using "Xen VM control pseudo-encoding", "Xen VM control > client message" and "Xen VM control server message"? I think it is fine to have it just named 'XVP - Xen VNC Proxy extension' since that's reflecting its origins, much like the other extensions here. I just think the descriptive text about the wire format should talk in generic functional terms. Regards, Daniel -- |: http://berrange.com/ -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://freshmeat.net/~danielpb/-o- http://gtk-vnc.sourceforge.net :| signature.asc Description: Digital signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
Daniel, Here's another iteration. I've tried to describe it independently of any particular implementation, apart from one sentence at the end. Does this look ok now to you? Thanks, Colin Describe the XVP extension The XVP (Xen VNC Proxy) extension allows a client to perform shutdown, reboot and reset operations on the system whose framebuffer it is displaying. Signed-off-by: Colin Dean --- Index: rfbproto.rst === --- rfbproto.rst (revision 3809) +++ rfbproto.rst (working copy) @@ -509,7 +509,7 @@ 253 `gii (General Input Interface) Client Message`_ 252 tight 251 Pierre Ossman SetDesktopSize -250 Colin Dean xvp +250 `XVP Client Message`_ === === Note that before sending a message with an optional message type a @@ -1043,6 +1043,27 @@ The event reports *count* valuators starting with *first*. +XVP Client Message +-- + +A client supporting the *XVP* (Xen VNC Proxy) extension sends this to +request that the server initiate a clean shutdown, clean reboot or +abrupt reset of the system whose framebuffer the client is displaying. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already +established that the server supports this extension, by requesting the +`XVP Pseudo-encoding`_. + Server to Client Messages + @@ -1066,7 +1087,7 @@ 254, 127VMWare 253 `gii (General Input Interface) Server Message`_ 252 tight -250 Colin Dean xvp +250 `XVP Server Message`_ === === Note that before sending a message with an optional message type a @@ -1208,6 +1229,31 @@ communications. A *device-origin* of zero indicates device creation failure. +XVP Server Message +-- + +This has the following format: + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - +XVP_INIT. + +A server which supports the *XVP* extension declares this by sending a +message with an XVP_INIT *xvp-message-code* when it receives a request +from the client to use the `XVP Pseudo-encoding`_. + +A server which subsequently receives an `XVP Client Message`_ requesting +an operation which it is unable to perform, informs the client of this +by sending a message with an XVP_FAIL *xvp-message-code*. + Encodings + @@ -1227,6 +1273,7 @@ -239`Cursor Pseudo-encoding`_ -223`DesktopSize Pseudo-encoding`_ -305`gii (General Input Interface) Pseudo-encoding`_ +-309`XVP Pseudo-encoding`_ === === Other registered encodings are: @@ -1245,7 +1292,6 @@ -306popa -307Peter Astrand DesktopName -308Pierre Ossman ExtendedDesktopSize --309Colin Dean xvp 0x574d5600 to 0x574d56ffVMWare === === @@ -1759,3 +1805,16 @@ where the standard input model is insufficient. It supports relative mouse movements, mouses with more than 8 buttons and mouses with more than three axes. It even supports joysticks and gamepads. + +XVP Pseudo-encoding +--- + +A client which requests the *XVP* pseudo-encoding is declaring that it +wishes to use the *XVP* (Xen VNC Proxy) extension. If the server +supports this, it replies with a message of type `XVP Server Message`_, +using an *xvp-message-code* of *XVP_INIT*. This informs the client that +it may then subsequently send messages of type `XVP Client Message`_. + +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference +implementation
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, May 27, 2009 at 07:10:13PM +0100, Colin Dean wrote: > Daniel, > > Here's another iteration. I've tried to describe it independently of > any particular implementation, apart from one sentence at the end. > > Does this look ok now to you? Yeah, this looks really good now. Regards, Daniel > Describe the XVP extension > > The XVP (Xen VNC Proxy) extension allows a client to perform shutdown, > reboot and reset operations on the system whose framebuffer it is > displaying. > > Signed-off-by: Colin Dean > --- > > Index: rfbproto.rst > === > --- rfbproto.rst (revision 3809) > +++ rfbproto.rst (working copy) > @@ -509,7 +509,7 @@ > 253 `gii (General Input Interface) Client Message`_ > 252 tight > 251 Pierre Ossman SetDesktopSize > -250 Colin Dean xvp > +250 `XVP Client Message`_ > === === > > Note that before sending a message with an optional message type a > @@ -1043,6 +1043,27 @@ > > The event reports *count* valuators starting with *first*. > > +XVP Client Message > +-- > + > +A client supporting the *XVP* (Xen VNC Proxy) extension sends this to > +request that the server initiate a clean shutdown, clean reboot or > +abrupt reset of the system whose framebuffer the client is displaying. > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === > + > +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, > +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already > +established that the server supports this extension, by requesting the > +`XVP Pseudo-encoding`_. > + > Server to Client Messages > + > > @@ -1066,7 +1087,7 @@ > 254, 127VMWare > 253 `gii (General Input Interface) Server Message`_ > 252 tight > -250 Colin Dean xvp > +250 `XVP Server Message`_ > === === > > Note that before sending a message with an optional message type a > @@ -1208,6 +1229,31 @@ > communications. A *device-origin* of zero indicates device creation > failure. > > +XVP Server Message > +-- > + > +This has the following format: > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === > + > +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - > +XVP_INIT. > + > +A server which supports the *XVP* extension declares this by sending a > +message with an XVP_INIT *xvp-message-code* when it receives a request > +from the client to use the `XVP Pseudo-encoding`_. > + > +A server which subsequently receives an `XVP Client Message`_ requesting > +an operation which it is unable to perform, informs the client of this > +by sending a message with an XVP_FAIL *xvp-message-code*. > + > Encodings > + > > @@ -1227,6 +1273,7 @@ > -239`Cursor Pseudo-encoding`_ > -223`DesktopSize Pseudo-encoding`_ > -305`gii (General Input Interface) Pseudo-encoding`_ > +-309`XVP Pseudo-encoding`_ > === === > > Other registered encodings are: > @@ -1245,7 +1292,6 @@ > -306popa > -307Peter Astrand DesktopName > -308Pierre Ossman ExtendedDesktopSize > --309Colin Dean xvp > 0x574d5600 to 0x574d56ffVMWare > === === > > @@ -1759,3 +1805,16 @@ > where the standard input model is insufficient. It supports relative > mouse movements, mouses with more than 8 buttons and mouses with more > than three axes. It even supports joysticks and gamepads. > + > +XVP Pseudo-encoding > +--- > + > +A client which requests the *XVP* pseudo-encoding is declaring that it > +wishes to use the *X
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, 27 May 2009 10:18:46 +0100 Colin Dean wrote: > > It would be really good if QEMU/KVM's VNC server supported this. > Can we agree on some naming, and then I'll submit a new patch. > > How about using "Xen VM control pseudo-encoding", "Xen VM control > client message" and "Xen VM control server message"? > Personally I think we should drop the Xen name completely (it could still be mentioned in the text as the origin though). Having something that sounds Xen-specific, even if it isn't, doesn't help adoption IMO. So my vote is "Virtual Machine Control ..." so that it's clear what this extension does even from just the name. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
Pierre, I'd be happy with that. Tristan allocated the numbers as "XVP", so do people think we should keep this as an abbreviation, i.e. refer to it as "XVP (virtual machine control) ...", or banish the letters "XVP" completely? Personally, I'd vote to keep the "XVP", just for consistency with RealVNC's document, and so one can refer to the "XVP extensions to RFB", which is more concise than "virtual machine control extensions to RFB". Thoughts? Colin -Original Message- From: Pierre Ossman [mailto:oss...@cendio.se] Sent: Thu 5/28/2009 2:49 PM To: DEAN C.C. Cc: Daniel P. Berrange; tigervnc-rfbproto@lists.sourceforge.net Subject: Re: [rfbproto] [PATCH] Describe the xvp extension On Wed, 27 May 2009 10:18:46 +0100 Colin Dean wrote: > > It would be really good if QEMU/KVM's VNC server supported this. > Can we agree on some naming, and then I'll submit a new patch. > > How about using "Xen VM control pseudo-encoding", "Xen VM control > client message" and "Xen VM control server message"? > Personally I think we should drop the Xen name completely (it could still be mentioned in the text as the origin though). Having something that sounds Xen-specific, even if it isn't, doesn't help adoption IMO. So my vote is "Virtual Machine Control ..." so that it's clear what this extension does even from just the name. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
Den 2009-05-28 18:34 skrev DEAN C.C.: > Pierre, > > I'd be happy with that. Tristan allocated the numbers as "XVP", so > do people think we should keep this as an abbreviation, i.e. refer > to it as "XVP (virtual machine control) ...", or banish the letters > "XVP" completely? Personally, I'd vote to keep the "XVP", just for > consistency with RealVNC's document, and so one can refer to the > "XVP extensions to RFB", which is more concise than "virtual > machine control extensions to RFB". > > Thoughts? Reboot, shutdown and reset are at least somewhat related to power. How about some construct along the lines of: eXtension for Virtual machine Power options. Maybe too contrived? Cheers, Peter -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
That sounds like a perfectly good description, Peter. Pierre: would you be happy if I changed all occurrences of "(Xen VNC Proxy)" in my patch to "(eXtension for Virtual machine Power options)"? Colin -Original Message- From: Peter Rosin [mailto:p...@lysator.liu.se] Sent: Thu 5/28/2009 7:20 PM To: DEAN C.C. Cc: tigervnc-rfbproto@lists.sourceforge.net Subject: Re: [rfbproto] [PATCH] Describe the xvp extension Den 2009-05-28 18:34 skrev DEAN C.C.: > Pierre, > > I'd be happy with that. Tristan allocated the numbers as "XVP", so > do people think we should keep this as an abbreviation, i.e. refer > to it as "XVP (virtual machine control) ...", or banish the letters > "XVP" completely? Personally, I'd vote to keep the "XVP", just for > consistency with RealVNC's document, and so one can refer to the > "XVP extensions to RFB", which is more concise than "virtual > machine control extensions to RFB". > > Thoughts? Reboot, shutdown and reset are at least somewhat related to power. How about some construct along the lines of: eXtension for Virtual machine Power options. Maybe too contrived? Cheers, Peter -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Fri, 29 May 2009 07:29:40 +0100 "DEAN C.C." wrote: > That sounds like a perfectly good description, Peter. > > Pierre: would you be happy if I changed all occurrences of "(Xen VNC > Proxy)" in my patch to "(eXtension for Virtual machine Power options)"? > It's a lot more generic, so yes. Although I don't think that it would be a problem to loose the connect to the XVP acronym and avoid this convoluted backronym. I don't think people will be that confused by different names in RealVNC's and our spec. :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Fri, 29 May 2009 07:29:40 +0100 "DEAN C.C." wrote: > That sounds like a perfectly good description, Peter. > > Pierre: would you be happy if I changed all occurrences of "(Xen VNC > Proxy)" in my patch to "(eXtension for Virtual machine Power options)"? > It's a lot more generic, so yes. Although I don't think that it would be a problem to loose the connect to the XVP acronym and avoid this convoluted backronym. I don't think people will be that confused by different names in RealVNC's and our spec. :) I suggest just stick with "xvp", which is what it's been called up to now. After all, it could be applied to systems other than virtual machines, so having a name with "virtual machine" in it is unnecessarily restrictive. Attached is another attempt at a patch. If anybody would like to modify it further, please just go ahead and do so. Cheers, Colin Describe the xvp extension The xvp extension allows a client to perform shutdown, reboot and reset operations on the system whose framebuffer it is displaying. Signed-off-by: Colin Dean --- Index: rfbproto.rst === --- rfbproto.rst (revision 3823) +++ rfbproto.rst (working copy) @@ -788,7 +788,7 @@ 253 `gii Client Message`_ 252 tight 251 `SetDesktopSize`_ -250 Colin Dean xvp +250 `xvp Client Message`_ === === Note that before sending a message with an optional message type a @@ -1413,6 +1413,27 @@ should make every effort to preserve the fields it does not wish to modify, including any unknown *flags* bits. +xvp Client Message +-- + +A client supporting the *xvp* extension sends this to request that the +server initiate a clean shutdown, clean reboot or abrupt reset of the +system whose framebuffer the client is displaying. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already +established that the server supports this extension, by requesting the +`xvp Pseudo-encoding`_. + Server to Client Messages + @@ -1436,7 +1457,7 @@ 254, 127VMWare 253 `gii Server Message`_ 252 tight -250 Colin Dean xvp +250 `xvp Server Message`_ === === Note that before sending a message with an optional message type a @@ -1593,6 +1614,31 @@ communications. A *device-origin* of zero indicates device creation failure. +xvp Server Message +-- + +This has the following format: + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - +XVP_INIT. + +A server which supports the *xvp* extension declares this by sending a +message with an XVP_INIT *xvp-message-code* when it receives a request +from the client to use the `xvp Pseudo-encoding`_. + +A server which subsequently receives an `xvp Client Message`_ requesting +an operation which it is unable to perform, informs the client of this +by sending a message with an XVP_FAIL *xvp-message-code*. + Encodings + @@ -1613,6 +1659,7 @@ -223`DesktopSize Pseudo-encoding`_ -305`gii Pseudo-encoding`_ -308`ExtendedDesktopSize Pseudo-encoding`_ +-309`xvp Pseudo-encoding`_ === === Other registered encodings are: @@ -1630,7 +1677,6 @@ -273 to -304VMWare -306popa -307Peter Astrand DesktopName --309Colin Dean xvp 0x574d5600 to 0x574d56ffVMWare === === @@ -2329,3 +2375,16 @@ need to parse the list of screens and can simply display the entire framebuffer.
Re: [rfbproto] [PATCH] Describe the xvp extension
On Fri, 29 May 2009 21:41:22 +0100 Colin Dean wrote: > > I suggest just stick with "xvp", which is what it's been called up to > now. After all, it could be applied to systems other than virtual > machines, so having a name with "virtual machine" in it is unnecessarily > restrictive. > A very good point. So something along the lines of "Power Control Pseudo-encoding" then. :) I won't veto this addition based on the name, but I strongly believe that we should make every effort to produce general extensions so that we don't end up with multiple almost identical ones. > +xvp Server Message > +-- > + > +This has the following format: > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === How should the client react if it sees a higher version number? > +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference > +implementation, which allows shutdown, reboot and reset of virtual > +machines running on Citrix XenServer. Does this page add anything to the protocol definition? We don't have official reference implementations for anything else, so I'm sceptical about adding one here. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
Den 2009-06-01 11:37 skrev Pierre Ossman: > On Fri, 29 May 2009 21:41:22 +0100 > Colin Dean wrote: > >> I suggest just stick with "xvp", which is what it's been called up to >> now. After all, it could be applied to systems other than virtual >> machines, so having a name with "virtual machine" in it is unnecessarily >> restrictive. >> > > A very good point. So something along the lines of "Power Control > Pseudo-encoding" then. :) > > I won't veto this addition based on the name, but I strongly believe > that we should make every effort to produce general extensions so that > we don't end up with multiple almost identical ones. I think the point Colin is trying to make is that he wants to stick to xvp as that name has already been exposed, google has indexed it etc etc. Changing the name this late will only cause confusion. So, instead of trying to find some (poor) expansion of xvp, we just leave it at xvp and describe what you can do with it (and maybe include a note about where the name originated for the curious, but in that case state that the uses are more general than the original name implies). Cheers, Peter -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Mon, Jun 01, 2009 at 01:09:44PM +0200, Peter Rosin wrote: > Den 2009-06-01 11:37 skrev Pierre Ossman: > > On Fri, 29 May 2009 21:41:22 +0100 > > Colin Dean wrote: > > > >> I suggest just stick with "xvp", which is what it's been called up to > >> now. After all, it could be applied to systems other than virtual > >> machines, so having a name with "virtual machine" in it is unnecessarily > >> restrictive. > >> > > > > A very good point. So something along the lines of "Power Control > > Pseudo-encoding" then. :) > > > > I won't veto this addition based on the name, but I strongly believe > > that we should make every effort to produce general extensions so that > > we don't end up with multiple almost identical ones. > > I think the point Colin is trying to make is that he wants to stick > to xvp as that name has already been exposed, google has indexed it > etc etc. Changing the name this late will only cause confusion. > > So, instead of trying to find some (poor) expansion of xvp, we just > leave it at xvp and describe what you can do with it (and maybe > include a note about where the name originated for the curious, but > in that case state that the uses are more general than the original > name implies). I'm sorry for starting this thread now. I think keeping the existing xvp name is the right answer. Many of the existing extensions are simply named after the product initiially defining the extension. We shouldn't try to rename them now. I merely wanted the descriptive text in the spec of the extension to be generic, leaving "xvp" as the name. Regards, Daniel -- |: http://berrange.com/ -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://freshmeat.net/~danielpb/-o- http://gtk-vnc.sourceforge.net :| signature.asc Description: Digital signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
Hi all, >> I think the point Colin is trying to make is that he wants to stick >> to xvp as that name has already been exposed, google has indexed it >> etc etc. Changing the name this late will only cause confusion. >> >> So, instead of trying to find some (poor) expansion of xvp, we just >> leave it at xvp and describe what you can do with it (and maybe >> include a note about where the name originated for the curious, but >> in that case state that the uses are more general than the original >> name implies). Peter has got my point: there's already been discussion on the Citrix mailing lists, and I made public a self-contained spec for the extension, in a style to match the RealVNC spec: http://www.dur.ac.uk/c.c.dean/xvp/rfb-extensions.html both using the "xvp" name. Re Pierre's point ... >> +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference >> +implementation, which allows shutdown, reboot and reset of virtual >> +machines running on Citrix XenServer. > > Does this page add anything to the protocol definition? We don't have > official reference implementations for anything else, so I'm sceptical > about adding one here. ... I put this wording in at Daniel's suggestion. Can I suggest we probably have spent enough time on this thread (!) and ask somebody to sign off and apply my most recent patch (from Friday evening)? Thanks, Colin -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Mon, 01 Jun 2009 12:51:13 +0100 Colin Dean wrote: > >> +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference > >> +implementation, which allows shutdown, reboot and reset of virtual > >> +machines running on Citrix XenServer. > > > > Does this page add anything to the protocol definition? We don't have > > official reference implementations for anything else, so I'm sceptical > > about adding one here. > > ... I put this wording in at Daniel's suggestion. > This discussion must have been off-list, or on some other list, so I'm not aware of the idea here. Do we want to start adding official reference implementations? I'd rather we try to make the spec good enough on its own and solve any ambiguities on a case-by-case manner. Reference implementations are a cop-out IMO. > Can I suggest we probably have spent enough time on this thread (!) and > ask somebody to sign off and apply my most recent patch (from Friday > evening)? We can drop the naming discussion. But I think the above issue needs to be resolved, as does the issue of how future version numbers should be handled. Since it's just you and Peter Rosin who have implemented this extension, I'd say you're in a best position to specify the handling so that it doesn't break anything existing. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
Pierre, +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference > >> +implementation, which allows shutdown, reboot and reset of virtual > >> +machines running on Citrix XenServer. > > > > Does this page add anything to the protocol definition? We don't have > > official reference implementations for anything else, so I'm sceptical > > about adding one here. > > ... I put this wording in at Daniel's suggestion. > This discussion must have been off-list, or on some other list, so I'm not aware of the idea here. Daniel's suggestion on this list, 27 May: http://sourceforge.net/mailarchive/message.php?msg_name=20090527095936.GA31980%40berrange.com However, I have now removed the offending paragraph. We can drop the naming discussion. But I think the above issue needs to be resolved, as does the issue of how future version numbers should be handled. Since it's just you and Peter Rosin who have implemented this extension, I'd say you're in a best position to specify the handling so that it doesn't break anything existing. In the attached patch, I have attempted to address version numbering (see the server message description). Regards, Colin Describe the xvp extension The xvp extension allows a client to perform shutdown, reboot and reset operations on the system whose framebuffer it is displaying. Signed-off-by: Colin Dean --- Index: rfbproto.rst === --- rfbproto.rst (revision 3825) +++ rfbproto.rst (working copy) @@ -788,7 +788,7 @@ 253 `gii Client Message`_ 252 tight 251 `SetDesktopSize`_ -250 Colin Dean xvp +250 `xvp Client Message`_ === === Note that before sending a message with an optional message type a @@ -1413,6 +1413,27 @@ should make every effort to preserve the fields it does not wish to modify, including any unknown *flags* bits. +xvp Client Message +-- + +A client supporting the *xvp* extension sends this to request that the +server initiate a clean shutdown, clean reboot or abrupt reset of the +system whose framebuffer the client is displaying. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already +established that the server supports this extension, by requesting the +`xvp Pseudo-encoding`_. + Server to Client Messages + @@ -1436,7 +1457,7 @@ 254, 127VMWare 253 `gii Server Message`_ 252 tight -250 Colin Dean xvp +250 `xvp Server Message`_ === === Note that before sending a message with an optional message type a @@ -1593,6 +1614,36 @@ communications. A *device-origin* of zero indicates device creation failure. +xvp Server Message +-- + +This has the following format: + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - +XVP_INIT. + +A server which supports the *xvp* extension declares this by sending a +message with an XVP_INIT *xvp-message-code* when it receives a request +from the client to use the `xvp Pseudo-encoding`_. The server must +specify in this message the highest *xvp-extension-version* it supports: +the client may assume that the server supports all versions from 1 up to +this value. The client is then free to use any supported version. +Currently, only version 1 is defined. + +A server which subsequently receives an `xvp Client Message`_ requesting +an operation which it is unable to perform, informs the client of this +by sending a message with an XVP_FAIL *xvp-message-code*, and the same +*xvp-extension-version* as included in the client's operation request. + Encodings + @@ -1613,6 +1664,7 @@ -223`Desktop
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, Jun 03, 2009 at 11:17:44PM +0100, Colin Dean wrote: > Pierre, > > +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference > > >> +implementation, which allows shutdown, reboot and reset of virtual > > >> +machines running on Citrix XenServer. > > > > Does this page add anything to the protocol definition? We don't have > > official reference implementations for anything else, so I'm sceptical > > about adding one here. >>> > > ... I put this wording in at Daniel's suggestion. >>> > >> >> This discussion must have been off-list, or on some other list, so I'm >> not aware of the idea here. > > Daniel's suggestion on this list, 27 May: > > http://sourceforge.net/mailarchive/message.php?msg_name=20090527095936.GA31980%40berrange.com > > However, I have now removed the offending paragraph. > >> We can drop the naming discussion. But I think the above issue needs to >> be resolved, as does the issue of how future version numbers should be >> handled. Since it's just you and Peter Rosin who have implemented this >> extension, I'd say you're in a best position to specify the handling so >> that it doesn't break anything existing. > > In the attached patch, I have attempted to address version numbering > (see the server message description). ACK to this patch. Daniel -- |: http://berrange.com/ -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://freshmeat.net/~danielpb/-o- http://gtk-vnc.sourceforge.net :| -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, 03 Jun 2009 23:17:44 +0100 Colin Dean wrote: > > > > This discussion must have been off-list, or on some other list, so I'm > > not aware of the idea here. > > Daniel's suggestion on this list, 27 May: > > http://sourceforge.net/mailarchive/message.php?msg_name=20090527095936.GA31980%40berrange.com > Hmm... The reference was present already in your original patch though, albeit in a different form. > However, I have now removed the offending paragraph. > Ok. We can leave that discussion for a later time then. > > We can drop the naming discussion. But I think the above issue needs to > > be resolved, as does the issue of how future version numbers should be > > handled. Since it's just you and Peter Rosin who have implemented this > > extension, I'd say you're in a best position to specify the handling so > > that it doesn't break anything existing. > > In the attached patch, I have attempted to address version numbering > (see the server message description). > Looks very nice. I've applied the patch. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
