I'm learning about Redux from Flora Worley and the Dan Abramov videos she recommended.
The initial principle of a single state tree reminds of a whole bunch of different projects and ideas I've dabbled in.
Back in 1998, I wrote a draft of a paper called Rethinking websites as single documents the TL;DR of which is: what if you viewed the splitting of a web site into different web pages as just presentation. The logical structure of a site could be a single (semantically marked-up) document.
This concept then got extended and in February 1999, I wrote the following to the xml-dev mailing list:
For a while now, I've been thinking what an OS (or more likely shell) would look like if it took Unix's "everything as a file" to "everything as an XML element".
A system would be a single XML "uberdocument" (physically, separate entities, including unparsed for any non-XML files on the system but logically, the one XML document). Applications (which would themselves be nodes in the element tree) would operate on other nodes in the element tree.
There would be an application, for example, that got mail via POP or IMAP, represented it in XML and then attached it a particular point in the uberdocument. XSL could be used to sort the mail. XSL would also be used to view the mail.
It's XML for the sake of it, but I think it would be fun to try out.
To be clear: there's nothing XML-specific about the concept. It would apply to any tree structure with annotated nodes (including JSON and plain JS objects).
Two days later, I wrote to xml-dev:
[Isn't it funny they way you can carry around a crazy idea in your head for ages and then, out of nowhere comes just the discussion to trigger externalisation]
AN INITIAL IDEA FOR AN XML ÜBERDOCUMENT SHELL
What I would like to see initially, is a shell-like application that has an interactive command-line that takes shell-like notions such as a working directory (and the ability to change same), starting of applications, redirecting of input/output to/from files, piping to other application and applies them to an XML überdocument.
So this "shell" would have the notion of a working element (command 'pwe' (=pwd) will tell you what the working element is). You can change working element with the command 'ce' (=cd) followed by an XPointer.
Elements contain XML content or they could reference an unparsed entity (for the issue of whether by ENTITY attribute or XLink see below). Some unparsed entities (perhaps with an appropriate NOTATION) are applications that can be "run". Instead of files, these applications work on nodes in the überdocument element tree.
I imagine that applications would be a lot more modular as most of them would be working on exposed data structures. Rather than a monolithic email/PIM application, you'd have simple applications (applets? no; how about application elements => "applements"). One applement would POP your mail and graft in on to an element in the überdocument. Another (perhaps just XT running an XSL stylesheet) would list the subject headings. Another would enable you to read email. An editor applement would let you compose a reply message and then a final applement would send the mail via SMTP.
A GUI can come later, but for now, I'd love to see an implementation of what I've just described. In something like Python it should take no time at all to do.
<sidebar>
Is the überdocument a single XML document with multiple entities or more than one XML document?
At first I thought that entities would provide the perfect mechanism for an XML überdocument to be spread over multiple files. For at least two reasons, I now suspect XLink might be the way to go:
1) you can give the links semantics which might prove to be very useful 2) you avoid the document entity != legal external parsed entity problem I raised in an early post
That having been said, it is important to note that the whole point of the "überdocument" notion is that it is logically treated (perhaps not at the XML parser level but at a level not too higher up) as a single document. Changing working element involves giving an XPointer not URI+XPointer.
</sidebar>
A month later (March 1999), in reply to a different thread I posted:
Wouldn't that be great? The UNIX pipe model has suffered from not having a standard structured format, as has the /proc file system. Not to mention what this could do to an OS like Plan9 where "everything is a file" and textual formats abound...
This is pretty much what I was suggesting a little while ago on this list (in the same breath as überdocument). I'm still trying to find the time to work a bit more on it. I certainly have a lot of ideas about it so if others are interested in helping with implementation, I'd love them to drop me an email. My idea involves a layer on top of the operating system that treats the operating system as one big XML document (hence the phase "überdocument shell" which I used at the time).
I'm thinking of calling it "Plan X" which both includes the mandatory "X" for association with XML and suggests, via roman numeral, a continuation of the thinking of Plan 9.
The TL;DR so far is basically:
By 2003, I was thinking about the idea of a filesystem entirely made of Python objects. This directly led to the somewhat different idea of the Cleese OS project.
Around this time I was still thinking a lot about tree-based personal information managers.
The only record of my ideas at the time I can find is this blog post: Using the Leo Outliner as a PIM.
Briefly jumping ahead to the present, I recently started playing around with WorkFlowy and it continues this idea of "single-tree information manager".
But back to the mid-2000s:
Around this time I helped a friend, Ashley Aitken, with a startup idea he had for a single-tree information management solution aimed at enterprises.
The node publishing features of WorkFlowy remind me a lot of what Ashley was thinking of (although his was a lot more advanced and he was doing a lot of work on versioning).
I was pretty deep into SVN at the time and SVN actually presented a really interesting model of tree versioning that was relevant to all this.
A few years later when I was going deep to try to grok git, I started thinking about generalising git's approach to versioning beyond blobs to data structures.
This led to Rev which was specifically about applying git-like concepts to Python data structures—an idea I still think has merit and would be interesting to go back to.
But there's this theme running through all of this which is this idea of a single tree (okay, DAG in the case of git) representing state: whether it be an entire filesystem or an information store for an individual or enterprise.
As I continue to learn more about Redux, I can't help but relate it to some of these ideas.
GraphQL fits in to a LOT of this stuff.