feat: namespace configuration

[zepatrik]

Related issue

contributes to #303

Proposed changes

Adding a namespace config schema and required interfaces.

Further comments

The namespace names can be changed while the id always is fixed.

[zepatrik]

I would like to first merge #315 and adjust the query format a bit @robinbraemer
With this PR I realized that the namespace always has to be present in queries, even if the object ID is not included. Can you please add that in your PR?

[robinbraemer]

I assume this is because the server needs the tuples table name of the namespace, right?

I will add a comment in the ListRequest that the namespace in object is required.

[zepatrik]

Exactly, maybe you even want to split object into ObjectID and Namespace? Would be a cleaner approach then requiring a nested key in my opinion.

[robinbraemer]

Even if some queries do not specify an ObjectID, an Object represents a "resource/digital object" in a namespace.
I'd prefer not to dissolve the strong relation between an object_id and namespace for Query messages and keep the model self contained, just as in other RPC requests like Check, Write, etc.

Would be a cleaner approach then requiring a nested key in my opinion.

Maybe (or not?), IMO using the Object structure in a Query structure probably helps generally more developers that use and operate on the client side with various Objects from different namespaces (and keep the linking). It allows to just set the object field of the Query to their already locally cached Object, instead of separating out the Object fields object_id, namespace directly into Query fields.

It may be a small design detail, but an important one, that makes users more productive.

[zepatrik]

It is an important one for sure!
Keep in mind that not only objects are bound to a namespace but also relations. In the namespace config you have to define all relations for that namespace.
For that reason I think we should separate out the namespace and object id everywhere and have them as separate parameters. It will be cumbersome for clients to have these nested structures.
Also it is required for consistency between the APIs. Expand will have to have a namespace parameter but no object ID, as we need the namespace for the relation.

[zepatrik]

So I rechecked the paper, there seems to be no use case mentioned where a request is missing an object. Still, we should separate object ID and namespace everywhere IMO because the namespace is coupled in the same way to the relation, and therefore it should not be nested as we first drafted.

[robinbraemer]

Good, in this case, I'll remove the Object message so we now define and refer to a namespace and object using a single separate fields everywhere. It's great to find and make the API design as similar as proposed in the paper.

[robinbraemer]

What about <object> ::= <namespace>:<object_id> from 2.1 Relation Tuples in the paper? Is it misleading us? :)

Beside this, maybe we should carefully re-read the Read API and re-design the ListRequest based on use cases needed directly described in the paper? Do you find it appropriate at this stage? I'll try to design a Query strictly based on the use cases said in the first lines of 2.4.1 Read to show how an alternative would look like and then we can evaluate and choose one of the designs.

[zepatrik]

This is really just the grammar of the language used in the paper and does not have to correspond 💯 % to the underlying data structures. Maybe there is also a limitation of zanzibar that every request has to include an object. But this would not be a) easy to grasp for people and b) technically required.

[robinbraemer]

How about renaming the string fields object_id to simply object, now that the Object message is gone?