Places to Look for PORT! Prior Art

It's probably useful to gather some resources on places to look for comparison/contrast/inspiration for I/O designs. So post here if you have them. I'll list a few:

Boost.ASIO

The C++ world has a powerful offering of Boost.ASIO, which stands for "Asynchronous I/O".

Boost.ASIO Overview

The focus is to link up various "easily leaky" C-style things into the C++ world, where things can be wired together more robustly. Of course, to take advantage of that, one must be able to read source that looks like these examples:

https://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio/examples.html

...which aren't necessarily all that complex when you boil down the syntax. But I haven't really used it. I feel like sitting down with it might be educational for me, and perhaps how they've broken down the problem could have easier-to-read parallels. One might even imagine using C++ in the implementation, at least for starters, if it demonstrated benefit.

Node.JS

JavaScript is single-threaded, Node.JS was sort of rapidly put together, and people seem to have been hacking up Node.JS programs fine. As far as I recall, Node didn't try to attack every kind of I/O through some kind of uniform interface. You just have objects that you pass callbacks to when they got the information you requested. Here's a description of how to do file I/O:

How to read files in Node.JS

It raises the question of how wise it is to try and pipe everything through one kind of READ and WRITE, vs clip: make clipboard! ... then clip/read, where the parameterization and data return types can all be customized by that object.

0MQ

I don't know a ton about 0MQ, but when I think about the idea of what some kind of unified-futuristic-I/O-model might do for someone, it's the kind of idea that comes up. What if PORT! always spat out blobs of Rebol values?

One scenario I think is interesting to model is two Rebol apps on a network, where one is able to send Rebol-styled data at a certain rate, and the other end can receive it and process it with PARSE. What might that look like?

Uniserve

I've never used Uniserve:

https://www.softinnov.org/rebol/uniserve.shtml

But supposedly it was a driving factor in creating Red. Yet Red lacks I/O.

It was created to address a perceived deficiency in Rebol2. Did it? Was it in competition with R3-Alpha ports? Does anyone who's used it have good things to say about it, bad?

This would seem to be scheme dependent. This is indeed how my REST scheme works: requests a web page and returns an object representing the target resource. This is also how the MySQL scheme functions—you can specify a query and it'll return the response as blocks of Rebol values.

This could be a pair of schemes—client/server—that would on initiation create a client/server TCP (or UDP) port and serialize/deserialize outgoing/incoming data.

Server:
image

Topaz

Here is an overview of Topaz--which as far as we know is not happening:

https://github.com/giesse/Project-SnowBall/blob/master/topaz/concepts.rmd

Interesting to look at is what he says about "promises" as a way to reconcile the convenience of synchronous I/O with the flexibility of asynchronous I/O. Yet he points out a weakness--in that you can't delay evaluation products if they drive conditional code.

I suspect what he suggests drives too far away from what Rebol is actually capable of under its paradigm, but putting it here for study.

0MQ is at the same network layer as http. Although interactions can be in lock step, they can also be asynchronous though you need to keep polling for results rather then being event driven. I'm not seeing much added benefit for using the port model here.