macro recorder

[Keith T. Adeney]

I had a look at a fairly competent macro recorder/scripter for windows
(Macro Express 99). The kinds of macro commands they offer can be
grouped as follows:

Interaction Simulation (Mouse/Key), Window Handling
(Activate/Close/...), Sound (Volume/Balance/...), CD-ROM (Play/Next
Track/...), Clipboard (Copy/Paste/...), Macro (Run/Playback Speed/...),
File Handling (Copy/Delete/...), Desktop Control (Wallpaper/Tile
Windows/...), Wait Events (for Window/for Program Terminate/...), and
others.

>From looking at these perhaps think three types of 'plugins' could be
useful:
	recorder, scripting/wizard, and service.

Recorder plugins would be able to record and playback RFB messages
(putting a recorder on the server/client end would make it easier to
repeat obscure system bugs).
Scripting plugins would add to VNC the ability to send commands
generated by your favorite scripting language (Java, Tcl, Perl, ... oh
and VBScript).
Wizard plugins would use the same interface as the scripting plugins,
but would focus upon doing some specific job(s) easily (open connection
to daily build machine, start daily build, retrieve error log).
Service plugins would add a new 'service' to VNC like file handling
(copy a file, transfer a file, ...).
Of course a plugin could be all the above rolled into one.

The new plugin RFB structure could look as follows:
from client to server ->
	plugin service identifier
	plugin service request description identifier
	plugin service request private data

from service to client ->
	plugin service identifier
	plugin service reply description identifier
	plugin service reply private data

The recorder could choose to pick up all three of the plugin RFB fields,
or pass the first two fields to a plugin offering the service identified
and let it generate the private data (for example the description could
be 'send file readme.txt' then the private data would be the contents of
the readme.txt file).

The recorder plugin interface would have to let it hook into the RFB
message chain. (Note: a flag might have to be introduced so that a
recorder doesn't record something it generates through a service
plugin.)

The scripting/wizard to VNC plugin interface would need to enumerate all
service plugins, and retrieve a reference to them, in addition a human
readable text (HRT) to numeric index mapping table of the available
service identifiers should be accessible through VNC.

The scripting/wizard to service plugin interface should allow the
service request/reply identifiers to be mapped to and from HRT. Also the
scripting/wizard should be able to ask the service to 'generate a RFB
message' (passing through supplied private data / generating the
corresponding private data / verifying the supplied private data).

Alternatively the mapping tables could be invisible and all plugins
could communicate using HRT.

I know that I have left out a lot of details, but I hope that these
thoughts on the matter might be helpful.

keith

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