frequently asked questions
m-ld is being actively developed. It is currently available as a preview for developers, welcoming feedback and interest. The documentation includes a number of indications of forthcoming features. Also see the main repository for other active requests.
m-ld should not be used in production scenarios or for sensitive data, yet.
m-ld stands on the shoulders of giants. It utilises a combination of:
- published computer science, to provide its data convergence characteristics, and
- data standards like JSON, RDF and JSON-LD, to provide interoperability and future-proofing.
The specification and implementation of m-ld's core will be published as soon as possible online, in computer science literature, and as free and open-source software.
m-ld is a data store, but it has a very different approach to a back-end database. A database stores all of the data centrally, on a server, and provides an API over the network for an app to access and update the data.
m-ld turns this model completely on its head. The data is stored locally, in the app, and is synchronised automatically with other instances of the app. If there is a central server, then it might also have a copy.
Notice that even in the app using a database, there is still a local copy of the data in the user interface, or some other in-memory 'model'. So the main practical difference is how much effort the app itself needs to put into keeping its own copy 'up-to-date'. In m-ld this is automatic.
m-ld data is secured in motion and at rest, in collaboration with the app using m-ld for data.
A clone obtains and maintains the current app state using realtime messaging, which can be configured securely. This will typically comprise authentication of the user and encryption of the data on the wire.
A clone may also allow the data to be encrypted when persisted to disk. Where this is supported, it is specific to the clone engine.
See the security section in the documentation for more details.
m-ld is a protocol and a set of engines to help software engineers deliver sharing of structured data. Using m-ld allows features such as online collaboration, offline editing, and data synchronisation to be delivered in less time, with less cost, and more reliably.
m-ld should not be considered for the complete management of big data (although it can be part of a big data architecture), for sharing of binary files, or for sharing of high-rate raw data (e.g. above 60Hz).
m-ld is usually deployed embedded in your app so that access latency is zero, and data from other users is visible immediately. So, first you need a m-ld engine for your app's platform. Alternatively, you could use a clone deployed on a server (for example, using a Docker microservice).
Finally, if your app requires data to be persisted even if all user devices have removed the data, you may need a clone deployed on a server, which stores the data onto disk.
The data is physically stored locally to an app in a clone, which is typically embedded in the app via a library called an engine, or very close by in a local process. Different clone engines may:
- Keep the data in memory only
- Persist the data directly to disk
- Use some platform-specific local storage
Logically, data belongs to a domain, which is a collection of clones that belong to it. An app could use one or more domains for different purposes.
m-ld is one of a number of technologies for data, with different trade-offs and strengths. These range from decentralised realtime data stores, through blockchain-based consensus systems, to NoSQL and relational databases.
The choice of m-ld might be particularly driven by:
- the need for realtime data updates for live decision making on derived data and knowledge;
- integration of data sharing features into existing apps;
- your deployment environment platform types.
Please do contact us to discuss your requirements. We are as keen as you are that your data management solutions do solve your data management problems!