💾 Archived View for bbs.geminispace.org › u › gyaradong › 19615 captured on 2024-12-17 at 15:16:05. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "When it comes to arbitrary, "realtime" composability, the..."
zzo38: OMG this is exactly along the lines that I've been thinking. The idea is: Programs operate on files, the files use a common data format (I was thinking RDF but it seems the Open Semantic Framework ties CDF and RDF together anyway). The files can be transferred between programs, either a subset of what the program operates on, or the whole "database". This file manipulation and streaming is then the UI paradigm.
EDIT: Also, this kind of gives you a similar model to the PalmPilot: You can "sync" by just transferring files which all parties can understand (common data), and you can share subsets of data through a common interchange.
Sep 12 · 3 months ago
Perhaps not quite exactly, but it is similar.
My idea involves a custom file format for the Common Data Format, which is not RDF (which has many problems in my opinion). Perhaps it can be: the command code (one bit indicates constructed or primitive), the length, and the data; if it is constructed then the data is zero or more Common Data Format items but if primitive then it is plain data. There will be many commands for common data but also extension commands are possible too.
About the file system design: There are no file names and no directory structures. It is a transactional file system. Files have multiple forks/streams (labeled by 32-bit numbers), and a file stream can contain both byte sequences and links to other files.
One of the forks of a file might be used for the data type of the initial message. So, instead of just text for passing command-line arguments etc, it can specify the expected data type of the message, including any capabilities it should contain (which can themself have types), and tagged unions are also possible as well as structures and other types. This is a convention used by the command shell and other programs and is not something that the kernel knows about, and nothing stops you from sending a message that does not conform to the specified types if you really want to do (although it won't do so by default; if you are using the command shell then you must explicitly tell it to send a raw message).
Command, Automation, and Query Language is used in the command shell and it can be used for composability, hopefully better than UNIX does, and with command-line and GUI composing together. However, many functions of the GUI will not need the command shell to allow them to be composed together, but the command shell is still very useful for advanced uses and can do much more than the GUI does (and you can use both together).
The composability is possible by Common Data Format, by proxy capabilities, and by message passing, rather than just by text like UNIX is doing (although SCM_RIGHTS is something UNIX has which is similar than the capability passing that I have). Neither text nor GUI is more fundamental; capabilities and messages are more fundamental, in my system.
When it comes to arbitrary, "realtime" composability, the Unix model of files, streams, and processes has yet to be topped. GUIs are vey rarely composable, and also hard to script. It makes me think maybe composability has to be one dimensional, and textual. This idea that a keyboard is fundamental to a computer but a different pointing device doesn't feels slightly off. I wonder if there is an elegant multi dimensional method of composability which simplifies down to simple compute models and...
💬 gyaradong [mod] · 16 comments · 1 like · 2023-11-14 · 1 year ago