This is a follow-up to discussion in rust-lv2’s issue #23, since the risen questions are rather broadly scoped.
First, some introduction: LV2 uses RDF graphs notated in Turtle to describe all relevant information; For example how plugins are called and how many ports they have. One example of such a description would be the description of the fifths example.
The URIs that are required to write these descriptions are provided as Turtle files too, for example in the core specification. For plugins, these graphs aren’t very important, but hosts need to know the defined graph in order to identify, load and use plugins. Therefore, we need a way to evaluate the predefined graphs of the specifications and as well as the graphs describing plugin resources.
@Yruama_Lairba did some research and found out that the RDF ecosystem for Rust is pretty thin; You can read the issue comments for more info. This pretty much means that we have to develop this ecosystem on our own. There’s no way around it since it is absolutely necessary for a proper host framework.
From my point of view, we need the three components:
- An RDF triple store where you can dynamically add, modify and remove relationships. I don’t think that it needs to be multi-threaded or perfectly ACID, it only needs to load some turtle files and query the graph.
- Obviously, a parser that can load Turtle files in the aforementioned triple store. Some of this work has already been done, for example by the
rio_turtlecrate, which can be adapted for our needs.
- A serialization format that can be used as constants in Rust code. If the resource descriptions of the specifications should be shipped by the framework, it needs to be integrated into the code. The problem here is that most serialization formats for RDF structures are rather lengthy and optimized to be read by humans. Simply copying the Turtle files into Rust code would take about half a megabyte of space and you would still need to properly parse the data, which may also fail. For maximum comfort, space usage and performance, it might be wise do develop a custom format that can be read efficiently by a Rust program without needing to parse it.
What do you think of these requirements? Did I miss something?