vnc-list-digest V1 #440

[Micah Parrish]

> Micah Parrish wrote: 
> > 
> > I propose that new messages be added to the RFB protocol to handle 
> > platform-specific and descriptive data which can be used however the viewer 
> > wants. It should be easily extensible to accomodate new data types. This 
would 
> > be a means of adding new features to VNC, or using it in new ways, without 
> > fragmenting the protocol. 
> 
> It would be cool to do this with a plugin mechanism. 
> The server and client would provide a registration API 
> that would allow you to associate an RFB message type 
> (an integer) with a library and an entry-point name; 
> when a message of a registered type is seen, the proper 
> library is loaded (if necessary) and the registered 
> entry point called with the incoming buffer as an argument. 
> Then no more changes to the VNC core code would be 
> necessary to implement such features as file transfer, 
> HDD lights, or whaterer. I know Win32 and most Unices 
> support programmatic runtime loading of shared libraries. 
> How about Mac? 

I know that there are applications on Mac that use plugins (Netscape and 
Photoshop spring to mind).  Whatever mechanism for negotiating platform-specific 
and descriptive data that we use, it really needs to be simple enough to work on 
any platform.  I anticipate VNC expanding to a lot more platforms other than 
PCs... printers, routers, coke machines, stereos.
 
> Micah, are you actually scripting mouse and keyboard 
> events to a VNC viewer? I was just wondering the other 
> day if it was possible to get the location of a particular 
> control within a running application, so you could 
> send events at it via RFB; that would be an awesome test 
> tool! 
> 
> -- Joe 
> 

I'm attempting to develop a test tool with which I can control a remote PC from 
a script on a unix box.  I've got the button presses and mouse events working 
from a command line or a file (STDIN is next.... just as soon as I figure out 
how to do it) It's still a bit buggy.  It's based on the x2vnc program, which is 
based off of the 3.3.2r3 code.  What limits its usefulness as a testing tool is 
that I have no feedback other than pixel information (which can change depending 
on what I'm testing, etc.  A real headache.)  I've got an interesting workaround 
where I run with remote shell a ps.exe program (part of the UNIXDOS toolkit.  I 
forget the url.  Denicomp does the best rsh daemon for win95.) which gives me 
information like window parent, x,y,x0,y0, process ID, and fun stuff like that.  
I pipe the output into a file and do a diff on it against my last file to see if 
any new windows are up.  The trouble is it takes a looong time to get all the 
information back to my script.  It works, but it's a kludge.

That's why I want the cabability to add stuff without breaking the protocol.  I 
want to be able to see from my script if an event happens.

------------------------------------- 
Micah Parrish 
micah "at" hpbs1443.boi.hp.com   Tel:1-208-396-6522

---------------------------------------------------------------------
The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------