Correction.. i meant to say the virtualization "service" layer.. the bits that provide the server/client networking aspects in the Virtual Bridges tech. The lower virtualization layer on the server side is KVM when running on a linux server if I'm reading the other VERDE material correctly.
Posted Dec 10, 2008 2:41 UTC (Wed) by EmbeddedLinuxGuy (guest, #35019)
[Link]
I can't find any information about whether the client and server are proprietary but Virtual Bridges claims:
1. The client/server protocol is an open source extension of VNC.
"The VERDE Clients Protocol utilizes the Virtual Bridges VDI remote client protocol, an open source implementation combining the standard RFB (VNC) protocol with remote device access functions. This mechanism allows clients to remotely display server sessions even over low-bandwidth connections, as well as perform local device functions such as printing and audio playback... Given the open source architecture of the VERDE Client Protocol, the mechanism is completely extensible and can easily be amended to support new devices and platforms."
2. You can access your virtual desktop using an ordinary open-source VNC client or X11, albeit perhaps without all the bells and whistles of the "rich client". According to a quote in The Register, the client can
be "any device, wired or wireless, that talks X11, VNC, RDP, or runs
x86 Linux or Windows and can run our rich client application. This
covers most every type of popular client out there, including PCs,
laptops, workstations, thin clients, as well as today's subnotebook,
wireless, and mobile PCs."
Posted Dec 10, 2008 2:57 UTC (Wed) by jspaleta (subscriber, #50639)
[Link]
Thanks for the information. I'm more than happy to eat crow, publicly, if VirtualBridges is using an openly documented API for their tech.
If their client/server model is at least compatible with traditional VNC clients that would be welcome news. I apologize for not seeing that earlier. If the claim in that pdf is accurate, and the protocal is at the very least openly documented that most definitely assuages the deepest of my concerns. Even if the server and client code they sell in that deal is closed, having an open API means that an open implementation for both the client and the server can compete in the marketplace which is the most important thing.
If you able to dig up any authoritative reference that documents the protocol extension or if you find their sourcecode repository, please let me know so I can make the appropriate retraction here, but also on my blog.