sikuli-driver team mailing list archive

[daluu <question173786@xxxxxxxxxxxxxxxxxxxxx>]

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

daluu posted a new comment:
Yes, that is true of the startup delay, should have mentioned it. That
is a trade off to having a self contained application that allows API
access over the command line. I believe that is similar for executing
one Sikuli script at a time, using the Sikuli command line.

Alternative I can think of for optimized performance for command line
API access is to have XML-RPC server serving command (with Sikuli always
loaded) and a matching XML-RPC client that exposes similar command line
interface to the solution I've posted.

The point of the solution wasn't to expose a shell but easy command line
access to execute commands rather than scripts and also provide access
to Sikuli usage for non-programmers w/o having to write scripts or code.
And easy integration option via return codes to synchronize with
external test tools to determine pass fail (rather than handling that
inside Sikuli script, or using code like Java, Python).

In my work with automation thus far comparing with and integrating use
of Sikuli this way (w/ the 3-5 second startup) with using AutoIt and
Selenium (w/ XPath element locators), the startup delay is not so
horrible that you'd notice much of a major difference in automation
activity and performance. Maybe when you debug and you're impatient,
yes, but not in terms of actually deploying automated solution. Granted,
optimized speed is best, but this isn't slow as a turtle either.

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.