frequently asked questions
m-ld is a technology for enabling software to support collaboration on live data - between clients of the same application, or between different applications. It also enables applications to be used offline, with data automatically synchronised with other uses when reconnecting.
To learn more about how it works, see How does m-ld work? below.
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.
Within the scope of the m-ld protocol it is possible to achieve different trade-offs, to support a range of data and knowledge sharing use-cases.
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 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 pronounced 'meld'. So why is it spelled with a hyphen? Well, this is because the name is a play on words: the 'ld' stands for 'linked data', deriving from the JSON-LD data standard, which m-ld uses for robust identifier management.
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.
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 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).
You also need a supported messaging service. If you'd like to deploy your own, you could use Eclipse Mosquitto or Aedes, but it might be better to use a cloud service.
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.
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 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!