At present Rebol 2 is stuck in the past with no prospect of fixes, but there is no product currently available that is able to replace it. This makes updating an old Rebol 2 application such as Synapse EHR challenging. Although Atronix Rebol3 has R3GUI, the kernel of their Rebol is old comparatively speaking and is mainly rebol3 alpha.
So, hopefully here comes zeromq to the rescue. This script taskventsink.r2 creates jobs which it sends to 0MQ. We have another script - zmqwork.8th, and for testing, this is written in 8th, which polls 0MQ for jobs, and then sends the results back to 0MQ where they are then picked up by the first script.
Hopefully this means I'll be able to offload time consuming tasks to another program in an asynchronous fashion so that the Rebol2 VID is stable and able to respond, as well as access web services that use TLS 1.2 which are not accessible to Rebol 2.
I need to add GUIs for both the rebol 2 and 8th scripts to confirm the GUIs don't block.
Why didn't I use r3 for the worker? Because r3/hf lacks a working 0mq extension and GUI, and r3/a athough it has a GUI and 0MQ, it's too buggy.
ZeroMQ ported, but needs building attention on Windows. Most of the issue there is just that it's hard to fiddle the knobs on the build system in such a way that it can work on both Visual Studio and MinGW cross-compiled on Linux for an arbitrary third party library. (Things like ODBC are easier, because they are installed as part of the compiler and Windows development kit.)
Can't help with the GUI... not going to tackle that myself until the language fundamentals are all lined up. But as I've said, a good working language model should be able to be tied to some GUI if it were picked. It just makes little sense to do it ad hoc or poorly.
I'm sympathetic to the mission to make sure for any non-GUI purpose, Ren-C is better...and even hope to have a compatibility story. It should be as easy as putting an option in a module to make a mostly compatible system...at least one in which, if you have freedom to modify the code, you can do so in a way that will make it run under either Ren-C or Rebol2/Red.
But that is a running background agenda. The goal of lining up the language core and API so that it embeds well and shows off as fit-for-purpose is cross-cutting, and that's what's happening this year. libRebol is the name of the game--and whether it seems so or not, the language changes are all part of the experience of trying to build and cohere that.