sikuli-driver team mailing list archive

[RaiMan <question161532@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

RaiMan proposed the following answer:
I think, that more than one year after the big step to the new API (9.x
-> 10.x/X) and the implementation of many new features, it is time now
to revise/consolidate the API and overall design.

observations from the standpoint of a power user (based on one year
experience dealing with user questions):

-- the Jython and the Java layer are not synchronized
   - some methods only exist on one layer
   - many method signatures are different on the two layers
   - some features are implemented on the Jython level (so not available on the Java level)

possible enhancements looking top-down:

1 -- implementation of features should only take place on the Java level and should isolate all system dependencies (Java implementation level, the engine), the find(text)/OCR feature should be a separate engine jar.
2 -- the current Jython level should be reduced to interface only (no feature implementation) (Jython API, maps to/uses the engine)
3 -- the Jython script run feature should be separated from sikuli-script.jar in its own jar and have a Jython and a Java API (Jython script runner), should be configurable to use external Jython
4 -- there should be an additional Java API layer, that has the "same" classes/methods as the Jython layer and no implementation of features (Java API, maps to/uses the engine)
5 -- every support for any script running should be concentrated in sikuli-ide.jar (which uses the "3 -- Jython script runner"), it should have a feature to generate jar packages (all target systems) that can be run from commandline only needing Java being available.
6 -- the image capture/store feature and the preview feature should be available as a separate jar, so it can be used standalone or implemented into other IDE's/editors

with this concept, we would have a true engine and a true API, so both
could be exchanged/enhanced separately from each other (e.g. the vnc
challenge or Selenium integration). And we have some tools (IDE, script
runner, capture support, preview), that could be used or not.

The distribution package should be one jar, that contains everything and
a self running installer, that does everything needed on the respective
system (like the Jython distribution).

there should be separate packages available (or configurable from full download)
- basic Jython (1, 2, 3, 6)
- basic Java (1, 4, 6)
- basic complete (1, 2, 3, 4, 6)
- IDE basic (1, 2, 3, 5)
- complete (1 - 6)

For each of these different jars (1 - 6) there should be 3 levels of
developement (stable, bug fix/feature add, experimental) and separate
build workflows.

The distribution packages should have a configurable build workflow to
integrate private versions of the jars 2, 4 and 6 together with needed
other components.

Based on all this it would easily be possible to implement JRuby
scripting (exchange jar 2 and 3), a Scala API (exchange jar 4) or any
other API for environments, that can talk directly to Java. Even true
integration into other not-directly-Java-aware environments (Python,
Perl, Ruby, C, ...) would be possible rather easy (the API level has to
be implemented for the respective language and "connected" to the
engine's Java API).

One could implement an optional API version (even configurable), that
fully supports before/after-callbacks (generic and specific) for the
relevant features.

And it is easily possible to implement support for
changing/complementing the API (statically like today with extensions or
even dynamically on the fly during run).

Based on jar 6, there would be more motivation, to implement Sikuli
support into other IDE's or editors.

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