← Back to team overview

sikuli-driver team mailing list archive

Re: [Question #271271]: [RFC] Sikuli API implemented in Python and C

 

Question #271271 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/271271

Joseph posted a new comment:
>From glossing over the documentation you have already for the remote
Sikuli server, it looks like your current implementation runs a server
on the machine with the frame buffer, and accepts connections from
machines that then control what the server does. This is the reverse of
what I had envisioned, and I think the current end result is easy enough
to obtain with an RPC wrapper.

In my mind, it would make the most sense to write a scriptable command
server  that accepted connections from many clients, received frame
buffer updates from clients on a regular interval, and sent Sikuli
commands back. In effect, this would allow for the command server to
utilize OpenCL acceleration efficiently and cheaply (one OpenCL device
for many clients), and would reduce the work required by clients to
essentially sending frame buffer updates and receiving/executing
commands.

This architecture also allows the machines receiving commands to be
placed behind private networks and firewalls, and still communicate with
the machine sending the commands.

Bandwidth requirements could be reduced dramatically by only pushing
frame buffer updates when the screen changes, and since the clients are
no longer doing the CV work, on-the-fly JPEG compression should be
manageable. Clients might even optionally use a heuristic to determine
whether a frame buffer change was relevant to the running job, and
consequently whether or not to send it to the command server.

With the CV work being offloaded to a more capable machine, image
pyramids and feature matching should be more feasible to do in real
time.

Additionally,  since the server is controlling what's running on each
client, nothing needs to be changed or updated on the client, the code
only needs to be changed on the server. Job pools could be created,
where a handful of clients could be controlled by one script, and the
rest by another.

Of course, if a person wanted, they could run the client and server on
the same machine and get the same interface that we have now.

These are just my thoughts, and I want you to know that I think the work
you've done so far is fantastic.

-- 
You received this question notification because your team Sikuli Drivers
is an answer contact for Sikuli.