Boring stuff mostly today.
I did a lot of code cleanup and refactors, fixed a few bugs, but no huge changed code wise just yet.
I spent a lot of time planning the plugin system and inter process communication. I’ve typed up some of it and created mock files/directories here https://github.com/DJ-Laser/n16-shell/tree/design-docs
I settled on a design inspired by noctalia shell. Plugins will be shipped as folders containing a manifest (plugin.kdl), plugin binary, and resources (images, translation files, etc…)
Like noctalia, I plan to write a runtime to abstract over the communication protocol, but in rust instead of lua.
Each plugin will also be a single binary instead of one file per capability.
For the protocol itself, I looked at shared memory solutions, but deemed them to be unnecessary complexity and completely overkill for my scenario.
I will communicate over unix socket, passed to the plugin as argv[1] when spawning the plugin process.
The actual messaging will be a request-response protocol. Because I want to support long-running asynchronous operations, each request sent by the shell will have a message id, which can be used to send a response, fulfilling said message.
Also, messages can invalidate previous messages. The best example of this is a dynamic launcher provider.
If I’m making a provider that runs a web search on the query input, I will get lots of requests to update my matches list. If I have to run a (absurdly long for demonstration purposes) 5 second web search, my plugin will appear to freeze for a long time after the user types just a few characters. If instead it is allowed to cancel the web search early and not return results for an outdated query, the plugin will run much faster, only the normal 5 second delay after the last character, instead of 5*num_chars.