diff --git a/doc/ipc_doc/generated/html_full/about.html b/doc/ipc_doc/generated/html_full/about.html
index e1016cbc8..23a06f9c4 100644
--- a/doc/ipc_doc/generated/html_full/about.html
+++ b/doc/ipc_doc/generated/html_full/about.html
@@ -21,7 +21,7 @@
- Flow-IPC 1.0.1
+ Flow-IPC 1.0.2
Flow-IPC project: Full implementation reference.
|
@@ -122,7 +122,7 @@ Future directions of work
Networked IPC: At the moment all IPC supported by Flow-IPC is between processes within a given machine (node). A session can only be established that way for now. Extending this to establish IPC sessions via network would be easy. Unix-domain-socket-based low-level transports would easily be extended to work via TCP sockets (at least). This is a very natural next step for Flow-IPC development: a low-hanging fruit.
Networked "shared memory" (RDMA): While the preceding bullet point would have clear utility, naturally the zero-copy aspect of the existing Flow-IPC cannot directly translate across a networked session: It is internally achieved using SHM, but there is no shared memory between two separate machines. There is, however, Remote Direct Memory Access (RDMA): direct memory access from the memory of one computer into that of another without involving either one's OS. While assuredly non-trivial, leveraging RDMA in Flow-IPC might allow for a major improvement over the feature in the preceding bullet point, analogously to how SHM-based zero-copy hugely improves upon basic IPC.
Beyond C++: This is a C++ project at this time, but languages including Rust and Go have gained well-deserved popularity as well. In a similar way that (for example) Cap'n Proto's original core is in C++, but there are implementations for other languages, it would make sense for the same to happen for Flow-IPC. There are no technical stumbling blocks for this; it is only a question of time and effort.
-More architectures: As of this writing, Flow-IPC targets Linux + x86-64. MacOS/Darwin/FreeBSD support is attainable with a few weeks of work, we estimate. (Could tackle Windows as well.) Supporting other hardware architectures, such as ARM64, is also doable and valuable. We'd like to do these things: by far most of the code is platform-independent, the exceptions being certain internal low-level details typically involving shared memory and pointer tagging in the SHM-jemalloc sub-component.
+More architectures: As of this writing, Flow-IPC targets Linux + x86-64. macOS/Darwin/similar support is attainable with a few weeks of work, we estimate. (Could tackle Windows as well.) Supporting other hardware architectures, such as ARM64, is also doable and valuable. We'd like to do these things: by far most of the code is platform-independent, the exceptions being certain internal low-level details typically involving shared memory and pointer tagging in the SHM-jemalloc sub-component.
We welcome feedback, ideas, and (of course) pull requests of all kinds!
@@ -132,7 +132,7 @@ Future directions of work