From: Fred Kleinsorge [kleinsorge@star.enet.dec_nospam.com]
Sent: Thursday, September 09, 1999 9:30 AM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Sun Ray a good idea. Is there any counterpart of Compaq?

Jan Vorbrueggen wrote:
 
> Not at all. I think that some of the features are very useful - death of the
> device driving the display doesn't kill all of your session and, most
> importantly, the ability to move from display to display without restarting
> everything.
> 

This is the only reason I could think of for such a beast.  And it's a
mighty big hammer to solve the problem... of course, the original X11
architects *promised* that the protocol would be robust, and that
applications would be able to survive interruption in service... yeah,
right.

But the downside is that the remote display will be anything but speedy,
even if the server side MPEG encoded the differences, it's highly likely
to use significantly more bandwidth than simply running the X11
application remote.  Of course, this "SunRay" hack solves this by
requiring it's own dedicated LAN port.


> Now whether one would want this as a seperate product, with all the marketing
> hype attached, or rather something more like the thing you're describing, is
> quite a different question; but you, or rather your company, has been and
> still is sitting in a glass house regarding marketing, and shouldn't start
> throwing stones 8-).
> 

Hey, it would never have dawned on me that this would be an interesting
thing to do.  After all, the x-terminal failed, and the ultimate
x-terminal - the multia - failed.  The idea of a dumb frame buffer on
the end of a LAN wire as as new-age x-terminal doesn't seem like it
offers something new... I hope it's cheap.

What I can offer is a method to start independent "virtual" X11 server
sessions on any V7.1 or later Alpha VMS system with Motif installed. 
These virtual servers run a special CFB server which will create an
in-memory frame buffer in a named global section.  In addition, a named
global section is created for input.  The special CFB logic will also
provide in the header of the frame buffer section a operation counter
(changes when a drawing operation is done) and a bounding rectangle of
what area has been changed (a lock mechanism is provided to synchronize
the invalidation of the bounding rectangle).  Along with this, I will
provide the source to a very simple X11 application which maps the
sections, opens a "real" X11 connection to a workstation, and displays
the frame buffer contents.  It also will take input from the
workstation, and turn it into input for the virtual X11 session. 
Someone who wants to use alternate methods of transport or image
compression, can use the source as the basis with my blessing.  I'd
supply the DDX source, but it would not help much unless I supplied a
complete X11 server DDX build environment (yes, I know I've mentioned
doing this in the past and haven't gotten around to it).  In any case,
the sample display code would provide you with the ability to interact
with the virtual session from any X11 display (even a laptop running
eXcursion), located anywhere you are willing to put up with the
performance.

I'm not sure exactly what the limits are on the code right now (like how
many virtual sessions you can run).  I spent a few hours last night
brushing off 7+ year old code, and updating it to take advantage of
features I've added over the years.


> > Does anybody really want this for VMS?
> > Maybe I'll dusbrushing off 7+ year old code, and updating it to take advantage of
features I've added over the years.


> > Does anybody really want this for VMS?
> > Maybe I'll dust it off and put it on the freeware CD.
> 
> Yes. Please do!
> 


Give me a week or so to clean up the code, and package it up.  I'm doing
this as a completely unsupported tool, so there are no guarantees that
it will work 10 years from now when you are running VMS Version 11.2
;-).  However, if you can make a persuasive case why this should be a
standard supported feature, feel free to send me that input.