Local-only operation

[gsvarovsky]

For evaluation of m-ld-js as a local data store (particularly for RDF/Solid usages), it would help to be able to call clone without passing any remotes.

• This could also disable the Journal (no remote recovery)
• Implementation of NullRemotes
• If persistence is used, the domain would still be sharable later by re-initialising with a suitable remotes

[zg009]

Hello, I am interested in this project to extend for some of my own uses. First, thank you for making it public. It is a very excellent piece of work that I have used a few times. Since this was tagged "good first issue" I figured it would be an ok starting point. If it is not a suitable first issue for someone new to m-ld, please feel free to redirect me. If it is fine, I have a couple questions:

1. By disabling the journal, is this the same as effectively implementing JournalConfig and setting the fields to undefined on every instantiation?
2. Would a correct version of NullRemotes need to extend AbstractMeld? I noticed the constructor for NullRemotes takes no arguments. Would that not cause conflicts with the clone function signature?
3. I am unsure of this third requirement. I am guessing it is handled in the configuration provided by the user, so if I instantiate a new clone with MqttRemotes rather than "LocalRemotes" and the same Backend, it would be recoverable with the new remotes system?

[gsvarovsky]

Hi @zg009 thanks so much for your interest! This is certainly a reasonable place to start, yes. However it might be a bit different than I thought...

1. JournalConfig is just configuration for the journal. It might be nice to add a flag, enabled (default true), which turns on or off the whole Journal mechanism. However, see below.
2. No, NullRemotes does not have to extend AbstractMeld, which is just a utility. The constructor is called from within clone with some arguments, but they will just be ignored.
3. Yes, you are correct; this is not really a requirement but an observation! There's nothing to do here (except maybe add a test).

As a new thought, I don't think it's wise to allow the Journal to be disabled just by configuration, because if a 'real' remotes is used and there is no Journal, no clone will ever be able to recover. So, allowing the journal to be disabled is a function of the remotes in use. NullRemotes allows it to be disabled; all other remotes do not.

Since NullRemotes is inherently special, I think we could just allow the constructRemotes argument of clone to be undefined. We could do this in stages:

1. First, use something like NullRemotes internally, or possibly, just allows remotes to be undefined everywhere.
2. In future, disable the journal if no remotes are used and if the journal does not already exist.

What do you think?

[zg009]

Hello @gsvarovsky ,
Thank you for the insightful response. It is always nice to see a library which offers something new to the RDF and Linked Data ecosystems, and even better to learn more about it.

I am sorry for the late response. I was reading resources about CRDTs and more of the performance and design philosophy behind m-ld so I could give a (hopefully) more robust response.

I'll start with point 2 since it seems simpler: To me this approach logically makes sense. If a NullRemotes starts, then no journal is created. If a new clone tries to reach a journal that doesn't exist, then it is notified that this does not exist and a new one is created. If a clone uses no remotes, then disable the journal if the journal is nonexistence. I may need clarification on what "disabling the journal" means, but I am assuming this means "no clone can access the journal for this given domain", in which case if you are enabling a clone with no remotes but a journal exists, it may be beneficial to notify the user it is available if they have the given permissions.

For point 1, I cannot speak too well on this because I am not very experienced with your library. However, passing undefined in many places can be tough (from personal experience), especially in Javascript. My thought initially was have a DisabledJournalConfig implementation which simply throws warnings letting a user know that the journal is not available for the given domain.

If any of my assumptions are wrong please let me know and I will give it more and better thought with clarity.