Most of the JMRI community doesn¡¯t really think or talk in terms of ¡°abstractions¡±.
JMRI itself is entirely organized around (internal) events and listeners. Things like Logix, signal logic, etc, listen for changes in object state and react. At the lowest level, those listened-to objects are small things like individual sensors, turnouts, lights, icons on panels, etc. From those are built higher-level objects like signal heads and masts, signal logic, CTC elements, etc.
In certain cases, JMRI will also use threads to handle sequencing, in the usual sense of ¡°do X; wait for Y; do Z¡±, etc, sequencing. JMRI itself uses this pattern for i.e. control of operations across communication links, sequencing startup, etc. There can be many threads running in parallel, each operating their own sequence. A lot of scripting is done this way, because many model railroaders find it easier to think that way, and it¡¯s an easy way to build a little sequence of tests and operations. But please note that there¡¯s no practical limit on how many of those can be running in parallel, either for small things (sequencing the operation of a few sensors and turnouts) or something large and complicated. I know a local layout that¡¯s running over 80 threads in parallel (two per CTC control point because of how their CTC panel was coded) just fine during operating sessions, and it¡¯s doing just fine.
Dispatcher, Warrants, etc are all suitable for specific purposes, but if they¡¯re not suitable for you it¡¯s not so hard to craft a custom solution. (It¡¯s usually _much_ easier to create a custom solution than a general one what will work for lots of different purposes and layouts). All those tools started as efforts that somebody thought were suited to their specific application
When scripting, the best way to think about it is that you¡¯re writing Python (really Jython to ease Java access, but that matters little; JavaScript is also available if you prefer that) on top of a JMRI library that gives access to layout objects. There are no fundamental limits to what that can do that way. If you want to create your own class library that has abstractions you like, go ahead: You have the full power of the Python language available for OO, functional, relational or even dynamic programming. Use listeners, threads and other constructs as you¡¯d like; they all work.
For example, all the way back in 2006, there was a JMRI-driven layout (built by John Plocher with help from Dave Falkenburg and others) at the Java One conference that ran multiple interleaved trains: two in one direction around an oval with two sidings, with another one working its way in the other direction. That was done with (IIRC) one thread per train, plus JMRI-standard signal logic that was automatically setting and clearing up signals. One thread per train was a good way to get this specific demo up and running really quickly.
Bob
On Aug 14, 2018, at 3:16 PM, jamespetts via Groups.Io <jamespetts@...> wrote:
I am finding it very difficult to get detailed information on what abstractions that JMRI is capable of internally and what needs to be done by way of scripting - and I think that I am correct in concluding that scripting is not really suitable for large-scale abstraction logic, although if somebody has achieved this successfully, please do let me know, as this would be most interesting to observe. It looks like "AutoDispatcher 2" is perhaps the closest that anyone has come to this, but I cannot find any documentation on its capabilities, so it is very difficult to understand what this is really able to do (and this is already a very substantial piece of software in itself).
--
Bob Jacobsen
rgj1927@...
Bob Jacobsen