URL Patterns
The pattern of URLs in gm-data resembles the scheme used in Local setup. All paths are relative to a rood oid, and every root oid is an independent tree.
GM-Data does a similar thing. But there are quite a few verbs other than just pulling stream content. Since the system is multi-tenant, a root oid (long hash identifier) is associated with every directory, and also with every file. In gm-data, we use a scheme like this for everything:
The first part is the action, second part is the oid, and there is always a slash that begins the path.
In order to correctly store hyperlinked content, paths are equivalent. From a real installation:
At this url, we are pointing at a directory of content.
In the json that comes back, we see this oid and parent oid:
That means that this is an equivalent url:
And continuing to follow the properties for each parentoid:
And so on...
Where the parent oid is the root oid...
Looking at the properties of the root oid, we can see why it's the (or a) root. Its parentoid is all zeroes.
This pattern is applied for all of these verbs:
props
stream
list
history
derived
The GM dashboard will segregate statistics by these verbs. That is why the verbs are in the prefix of the URL.
This allows us to upload hyperlinked content and know that it will still work. For example, say that we upload a file called index.html with parentoid 1, and this file was assigned oid 99 for itself:
If images directory has an oid of 42, and cat.jpg is oid 66:
These are equivalent:
These are equivalent:
The html from window.location of /stream/1/ asking for images/cat.jpg will be fetched correctly by the html. The html cannot fetch by oid, because the static content won't know the oid of files until they are actually uploaded.
This functionality is critical for applications such as GIS, where you may upload a hyperlinked bit of html that loads Google Maps and has links to layers at predetermined names. It can't use oids, because the static content is uploaded into the system before oids are even known.
Multi-Tenancy
The use of a required oid for every path allows for multi-tenant scenarios. Presume that two organizations want to host gm-data content in the same system. (The permission syntax is explained later, but it's an expression compared against a user's JWT token to figure out permissions like Read, Execute, Create, Update, Delete):
The oid 1 is visible by everyone
The oid 100 is visible only to AliceCorp, with permission like:
(if (contains org alice) (yield R X))The oid 101 is visible only to BobCorp, with permission like:
(if (contains org bob) (yield R X))
Alice will do a listing of oid 1 to start listing data. Alice only sees the alicecorp directory, and does not know that bobcorp directory exists. If somebody from bobcorp shares out a file that's readable by everyone (yield R X).
Last updated
Was this helpful?