Immortal Object Server

This project arose out of OrgSuite 2.

Hierarchy

Meta-data consists of hierarchical tagging. If something is tagged as 'vegan' and vegan is a descendant of 'recipe' then that thing is automatically a recipe. Hierarchical tagging is used exclusively because all other systems of meta-data can be simulated through hietags (are you sure?). Hietags and objects are in a many-to-many relationship, so one object can be associate with multiple nodes.

Came across [this] article and it got me thinking about the hierarchies. By defining the parent as a range and having all children fall within that range, querying is made much easier. If you run out of room, there is some un-graceful re-balancing required, but that's not too bad. If I just allocate a large range for each, it shouldn't be a problem. I may also run into issues if someone attempts to add one whole tree into another, but I can just pull both of them out, rebuild them in php and put them in the database with adequate spacing. Basically each tag has an id and a highest-child-id.

Hietags

Obviously, each id is unique. But since user will primarily interact with tags via their, well, tag - we need a way to distinguish them. This can be done with namespaces. Users have a default namespace. Namespaces also have owners and permissions. Hierarchies can cross namespaces.

Users and Groups

Users store login credentials (username/password) as well as an access token. Users are in a MtM relationship to groups. Groups are structured as hierarchies. Each group has an id plus an r/l marker (and a name).

User groups are specified by having a root of 0 and they will have the same index as their user.

There's also a weird little loopback where groups have permissions over groups. So we'll need a group-group table. A user can a user to a group if they have user-admin permissions (a special permissions group) and they have admin permissions to that group.

Objects

Immortals are the Imobse root objects. They are are ordered (indexed as well as having non-unique) dictionary keys. One of the important features that an object supports is referencing another object. An empty string can be used as a dictionary key and since they don't have to be unique, an object with all empty strings would act like a list.

Scripts

Originally I was going to add a scripts layer, but I don't think that's necessary now. JS, CSS and HTML can be stored as objects and PHP can be stored as blobs. We will need to add an additional layer to restrict what sorts of blobs users can upload.

Because of the nature of php, read permissions to the blob are the same as execute permissions. Scripts are executed with the permissions of the script owner. I'm not precisely sure how I will manage that, but it's feasible.

Apps

Like scripts, I was going to have a whole structure, but that structure can be stored as data and blobs. So there is no special structure.

Files

This is a future-feature I would like to add, the ability to store certain file types (images, audio, txt, csv, .doc[x], pdf) and associate them with an object or hierarchy.

Queries

User can request an object by id, or a set of objects with a list of ids.

Tags are searched by title or id. If a namespace is not specified, the users default namespace is used.

Queries of course can be and/or'd together.

Permissions

Permissions are fairly standard, [read, read/write, read/write/admin]. Users can be grouped so that permission can be quickly given to a set of users. Permissions will be in a many to many relationship with objects. Groups have owners, also a permission (group).

When I mapped this out, I think permissions should only be assigned to groups, but each user is given their own group. It's a little sloppy, but the alternative gets ugly using either unions or a lot of redundancy for individual/group.

It would be nice to create a hierarchical grouping for permissions as well.

Permissions and Hierarchy

The hierarchy will also have a permissions layer. But, object and hierarchy permissions do not need to align. Hierarchies act like an index, so you could have access to a catalog where you may not be able to access all the material indexed. This allows

• Groups to maintain hierarchical indexes for shared objects
• Individuals to index a shared object in their personal hierarchy
• Individuals to place a personal object in a group hierarchy
• Hierarchically organized groups to place objects available to only a subset of the members in a broadly shared hierarchy

Permissions are inherited. So given A → B → C → D. If A is given RW permissions and no explicit permissions are set for B, C and D, then they will inherit RW permissions for the same context (user or group).

Blobs

Blobs can be uploaded and will act much like objects, they have a title and id. They can be linked to permissions and hierarchies.

Database Structure

• U: Users
• P: Permissions
• O: Objects
• B: Blobs
• H: Hierarchy
• S: Scripts
• A: Apps

V2

• U: users
• P: permissions
• O: objects
• B: blobs
• H: hierarchy
• N: namespaces

Clusters

Kind of a "round 2" thing, but I want servers to be able to be clustered. If you have a server, you can take a basic server and point it at the first and it will clone it. In order for this to work, we can't have any sequential indexes. Re-balancing trees may also require some special locks.