Multiuser Synchronized Distributed Database
As the GUI moves ahead, there's some talk around about how to do a lean synchronized distributed database for REBOL apps.
You already have one, you just don't know it yet. R3 Chat system (DevBase-2) is a third generation implementation of such a synchronized message-based database. It's a full redesign of what I implemented for AltME, which as a full redesign of what we implemented for REBOL IOS. I also learned some things from DevBase-1. So, that's about a ten year concept development span (but goes back even further if you consider my message-based systems developments began in the 1980s, with RPC prototypes, and implementations like the Amiga MT Exec, which even predates IBM MQ, 1992.)
The newest message-sync implementation solves many problems that earlier systems did not. For example, it solves the message deletion problem (which is more than just technical in nature), groups, threads, message movement between groups, file tagging, file sync, file renaming, file deletion, and much more. It's an excellent design, and one I've simplified to a tiny kernel of less than 10 KB (server and client.)
In addition, the system is "virtualized" -- in the VM sense of the word that messages can be fetched-on-demand -- reducing download overhead and client startup overhead if so desired. The approach also focuses on minimizing server overhead and loading, maximizing throughput, and efficient distributed backup. The same technique provides "user views" of shared data, where user-private data is only shared with those who are allowed to see it. User-selective snapshots.
It can be used for a lot more than just messages too. It's easily extended to contact database, calendars, file sharing, revision control, sales records, client info, and much more.
Anyway, I just thought I'd put this out there to see if there's any interest. I've not promoted it much, because I figured everyone these days was an SQL dead-head. The approach I use is much leaner, faster, and maintainable. But, it's not SQL, nor do I want it to be.