Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: libqaul API sketch #244

Closed
wants to merge 1 commit into from

Conversation

@NoraCodes
Copy link
Contributor

commented Jun 18, 2019

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.

Create trait for connections to 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 syncronous version are very easy to implement, but there is an
extended trait that provides a polling method for async implementations.
@NoraCodes

This comment has been minimized.

Copy link
Contributor Author

commented Jun 18, 2019

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.

spacekookie referenced this pull request Jun 27, 2019
@spacekookie spacekookie referenced this pull request Jun 27, 2019
@spacekookie

This comment has been minimized.

Copy link
Member

commented Jun 28, 2019

Replaced with #247

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.