Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: libqaul API sketch #244
Add a basic outline for communicating with services. This can be used for "internal" services or those exposed over some kind of network, or more exotic things. Service connectors that implement only the synchronous version are very easy to implement, but there is an extended trait that provides a polling method for async implementations.
I'd like to wait to merge this PR until it contains at least a dummy service so we can try out async-ifying things and such. However, I'm not sure precisely where this interface fits in, in terms of libqaul. Specifically, I'm not sure if we should implement the services like user management and local file management in-process (libqaul), in the qaul.net node process, or in external processes which communicate over the network.
This PR is called "API sketch" because I would really like to have a "sketch" of the basic services, as presented in https://cryptpad.open-communication.net/code/#/2/code/edit/HlymzFA07d+XvUcHXxj2mcI0/ , so I can work on simulating them.
On this topic, it seems to me like we have a number of options: we can have as many things as possible stay in process in libqaul; we can have libqaul communicate with the node to do everything; or we can have a mix of the two.
I personally am very much in favor of keeping things in process in libqaul. This is mostly because it would enable two valuable properties. First, it means that many operations, like user management, can be done without any intermediary; creating and editing users requires only the program actually working with them. Second, it allows the qaul node to use libqaul, which will mean no maintaining multiple versions of things.
However, it does have drawbacks, most notably that we have to ensure that no two qaul applications modify on-disk state simultaneously in a way that could lead to corruption.
The alternative is to only expose an API "wrapper" in libqaul. This is slightly different from the architecture given prior, as it would mean that both libqaul (e.g. the Message-based API) and the HTTP API are just "wrappers" for internal functionality inside the qaul.net node.
The hybrid approach would be more complex to implement, but has the advantage of allowing us to swap things around as needed, in terms of what is in process and what is not.