Immortal Object Server

This project arose out of OrgSuite 2. The Immortal Object Server (Imobse) stores objects as ordered dictionaries (each entry has two keys, a string and an integer where the integer set is continuous). Each object has a user, title, and data (the object).

Meta-Data

Meta-data consists of hierarchical tagging. If something is tagged as 'vegan' and vegan is a descendant of 'recipe' that that thing is automatically a recipe. Hierarchical tagging is used exclusively because all other systems of meta-data can be simulated through hietags. Hietags and objects are in a many-to-many relationship.

Ideally, I would like the query to do the recursive search of hierarchies, but I don't know if that's possible if not, when the hierarchy changes we could update a column to include all parents.

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 php and put them in the database with adequate spacing. Basically each tag has an id and a highest-child-id.

Immortals

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.

I am considering dropping the 'object' aspect all together and instead allowing collections of markdown to be grouped.

Scripts

• CSS
• JavaScript
• html

CSS and JavaScript will be included as links. HTML will be injected in the body.

Apps

An Imobse app is an ordered list of Scripts that manipulate Immortals. The original concept was born out of OrgSuite so I will use that as an example.

An personal organization app could be created by having scripts that support appointments through an interface contract that requires an appointment to have a "Date" attribute. The app can then display all objects with a "Date" attribute on a calendar. A user could choose to have all the objects for that app under a folder in their hierarchy so only 'OrgSuite' objects are manipulated by OrgSuite, or all objects with a Date attribute could be shown on a calendar, making Date semi-standard by convention.

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

• Title exact | matching
• ID
• Tag
  • Exact
  • Descendant
  • Matches multiple categories
• Is a file

Permissions

There are two permission settings, user and group. Users are ints and groups are strings, following standard variable naming convention [a-zA-Z_][\W]+. Groups also have an owner that follows the same rules.

Blobs

Blobs can be uploaded and will act much like objects, they will be given a title, owner and id. They can also be tagged.