From: Steve Cheng <elmert@ipoline.com>
  To  : GGI Mailing List <ggi-develop@eskimo.com>
  Date: Fri, 18 Sep 1998 16:08:14 -0400 (EDT)

display-tele suggestion...

I've looked at it, great work Andrew!

I have an ambitious suggestion :-)

Option to use UDP sockets, non-blocking, at least in ASYNC mode.  So when
the app calls ggiDrawPixel, it would try to send the (queued) event data
immediately, if not it will just queue it up and a ggiFlush() would wait
until all data has been sent.  

The problem is that the packets may be out of order, and if you got
overlapping operations the results will be incorrect.  The LibGGI doc states
that reordering accel operations may be done in ASYNC mode, but doesn't say
it is the responsibility of the application to ensure operations don't
overlap and cause glitches.  Any ideas?  Or a new flag like
GGIFLAG_REORDER_POSSIBLE ?

Anyway, if we need correct order, we can make use of the sequence number in
each event packet.  We need this anyway if the get/put buffer data, etc.
exceeds the size of one packet. 

When the teleserver gets a packet it will acknowledge, and ggiFlush() would
wait until it does that.

Or you could use ASYNC I/O, easier, for this functionality, but its not
supported everywhere.

Using this model would also allow "servers" to connect to the LibGGI
application at any time, by sending a packet to the running application.
A LibGGI VNC-lookalike, if you will :-)

The point of this exercise is, of course, to make optimal use of bandwidth.

I'll try implementing this and other fixmes once I digest more of the code.  
(My VNC target stopped working, so nothing else to hack :-(

Comments?

--
Steve Cheng

email: steve@ggi-project.org
www: <http://shell.ipoline.com/~elmert/>;