Closed ProofOfKeags closed 3 years ago
I am in the process of writing a replacement Haskell RPC library due to precisely this issue.
Currently, Project:M36 relies on distributed-process-client-server
even for in-process connections because it offers a uniform means of database discovery. (Project:M36 supports multi-tenancy databases.)
I will keep your use-case in-mind, but I would like to keep the notion of retaining the same API for remote and local databases.
@agentm I think distributed-process was removed?
Indeed, distributed-process has been completely replaced.
I'd like to be able to use this as a sqlite replacement. However, there is a hard dependency on CloudHaskell which doesn't seem necessary for in-process databases. I am also trying to get it to build on GHC 8.10.2 and it turns out that CloudHaskell is behind here. I've spent a couple of days trying to deal with dependency issues but the upper bounds on base and other "core" libraries means I have to get version bound relaxations on 5+ libraries that I ultimately won't use.
I saw another issue #198 that suggested the idea of dropping CloudHaskell altogether due to it not being maintained, but there was a reluctance due to the idea that there wasn't a replacement.
What is the barrier to dropping the distributed-process dependency, or at least factoring it out enough to not impact use cases that would otherwise not require it?