Re: gnome-network

["Erick Woods" <erick gnomepro com>]

My 2¢...

I agree that gnome should have a complete set of apps that allows the user
to easily share the desktop (rfb or rdp) and connect to other desktops (rfb
or rdp).  These should be in a single package to make life easier
(gnome-remote or similar).  I don't know if they should be in the core or
not because of dependancies.  Currently tsclient has to spawn an rdesktop
process and that just doesn't work well.  IMO, the rdesktop people should
create a library that could be used by other apps.  I suggested this to them
in the past.  rdesktop should be a command line tool that uses librdpclient.
Then, with tsclient or anything else, a gui can be created that is sane.

I know Jeff wants tsclient to get some "UI love", but IMO it is better left
in a state that resembles the windows version.  I have received a lot of
feedback from people who use both on a daily basis and for them or anyone
migrating from windows to gnome, it is easier to have one less gui change.
I also have the capability to read/write M$ rdp files, so bouncing between
clients is easy.  I did make some changes for HIG conformance, but more at
this point doesn't fit the goal.  I know it isn't the prettiest or most
functional, but it serves a purpose.  If anyone has suggestions, I am
willing to listen.  :-)

Erick
erick gnomepro com
http://www.gnomepro.com/



----- Original Message -----
From: "Havoc Pennington" <hp redhat com>
To: <desktop-devel-list gnome org>
Cc: <erick gnomepro com>
Sent: Saturday, December 07, 2002 10:24 AM
Subject: Re: gnome-network


On Sat, Dec 07, 2002 at 06:13:01PM +1100, Jeff Waugh wrote:
>   - rfb/rdp client: rfb is the VNC protocol, rdp is the Windows Terminal
>     Services protocol. We already have xvncviewer and rdesktop, so perhaps
>     just a frontend to these would be appropriate. TSClient [1] needs a
bit
>     of UI love, but it's a good start for rdesktop.

Nice, I hadn't seen tsclient. Cool. I did some research on how to
write an RFB *server*, so that we can have a "share my desktop now"
feature - I'll append my conclusions. Combined with tsclient that
should give us a pretty sweet feature. (Spamming tsclient author too
;-))

I really like the way tsclient does both rfb and rdp, so many free
software UIs make the mistake of a different frontend for every
backend.

This RFB server project is pretty small, order of 1000 lines of code
to get it working, it will probably grow a bit more than that over
time. Requires some thought, some security awareness, but not rocket
science. So I'm hoping someone will go for it.

It should be integrated with the client, so they use the same
terminology etc.

Both client and server belong in the core GNOME desktop release IMO.

Havoc

First, there are two use cases:

 1. SunRay-style headless X server; you run the server, and
    use it via VNC exclusively. For stateless desktop access
    similar to "screen" with a terminal.

 2. "Share my desktop" with easy GUI, means we need to be able to add
    VNC to any X server without restarting the X server.

Existing software:

 libvncserver: GPL library, includes all the vnc server hard bits.
               I guess based on the original vnc code. you just
               forward it the framebuffer contents and forward from it
               the mouse/keyboard events.

 krfb: KDE client-side VNC server that uses libvncserver and
       thumbnails the screen in a timeout. Also includes the GUI
       pieces. Fairly KDE-specific, uses DCOP for IPC, KConfig, etc.,
       and also contains some extensions to the basic VNC server
       features.

 xf4vnc: a sort of controlled fork of XFree with an XFree86 driver
         that forwards a framebuffer to VNC, for headless usage, and
         an XFree86 loadable module that allows any driver to export
         VNC functionality. The VNC code here is I think based on the
         original VNC code and is similar to the code in libvncserver,
         but does not use libvncserver.

 vnc: Red Hat "vnc" package is an X server based on XFree 3.3.2, so (I
      think?) does not address use case 2, and will also not have any
      of the newer X features such as render. Kind of dead-end-ish
      right? I haven't looked at this closely.

My suggestion is: the main VNC server is on the client side, as with
krfb. It uses libvncserver so doesn't contain much "real" code.
It is basically just a thumbnailer app that pushes the thumbnail
to libvncserver.

We add minimal hooks to XFree86 to make the client side VNC server
reasonably efficient, and get them into XFree. I believe these hooks
are:

 a) a headless driver that exports the framebuffer via shared memory,
    so the client side VNC server can get at it with zero copies (this
    is the SunRay-type use case). This should make the client side VNC
    server about as efficient as the server side one, or at least
    close enough.

    The "xvfb" headless X server in XFree CVS already has this shared
    memory feature ("man xvfb" for details).

    Two possible work items are:

      - export some way for clients of xvfb to get at the
        path to the mmap'd framebuffer (probably the
        xvfb server just sets a property on all root
        windows)
      - convert xvfb from deprecated framebuffer layer
        to new framebuffer layer so new extensions work
        right

    So to run a headless setup you just arrange for xvfb to fire up
    post-authentication, then you connect to it.

 b) an X extension to speed up thumbnailing on normal X servers
    (real hardware drivers, instead of the headless xvfb).
    This is used in the desktop sharing use-case.

    I did a simple and easy extension called "X-DAMAGE," see xpert
    archives, but keithp wants to do something more complicated.  In
    any case it will probably be in the next XFree release (after 4.3).

    Before the extension goes in, we can poll the screen in a timeout,
    like krfb; that fallback code is needed anyhow. And most of it in
    krfb doesn't look Qt-specific, so could just ask the krfb guy to
    use it.