Hierarchy, folders, authorization and nested (parent-child) relationships about atomic-data-docs HOT 5 CLOSED

I've been working on atomic-data-browser for a couple of weeks, and playing around with that made me feel even more hungry for some hierarchy. Some things that I want:

• I want to be able to find stuff by navigating a hierarchy
• When I open a resource I want to know where it is. I want to see its parent, see where it lives. I want a breadcrumb bar.
• When I open my app, I want to quickly see the most important types of content. I currently ordered this by generating a set of collections, which are fully dynamic and class dependent, but this fails whenever I make a new type of class.
• I want to share a bunch of stuff (a space / a folder / a tag) with other people. Not just for viewing, but also for editing.
• I want to constrain some pars of hierarchy to only contain certain things
• I want to see all my stuff in a notion-like sidebar, where I can collapse irrelevant items.
• I want to spend as little as much time possible on thinking about hierarchy when creating something new.
• I want to see which folders are eating up most of my storage space
• I want to be able to follow a thing (parent) and all its sub-things (children), receive notifications when any changes.

Approaches

Every item has a parent, only tags (folders) can be parents

• Simple to understand, will feel very familiar to any OS / dropbox / google drive
• Can be easily mapped to existing filesystems (for dropbox / drive like synchronization with desktops)
• Easy to implement consistent views for

Every item has a parent, any resource can be a parent

• Every time you make a new resource, you have a decent default parent: the currently shown item!
• Means that in terms of views, we kind of need every type of view to see children, or constantly have the ability to see children.
• Allows for using non-folder parents, which can be very useful. For example, comments may be children of some News Article, even though that news article is not a folder.
• Mapping to traditional filesystems may be hard. Maybe create a folder and add a file in there with the same name, or index to act as the 'main' resource?
• Creating

Parents are optional

• Will lead to items that may be unfindable, which can be difficult when finding disk usage culprits, for example.
• Easier to create content - no need to specify / think about parent.

from atomic-data-docs.

I think that making every item parentable is a pretty clean solution. Doing this means that every Atomic Data Server needs a root node. As a term, I feel like root is a bit too technical. I prefer drive, as a root node should feel like a hard drive.

But how should we order the rest of the content? Maybe the Drive has children, which are calculated dynamically, and we use the existing collections as children?

from atomic-data-docs.

Rights and grants (read / write access)

We'll definitely use the Hierarchy model to provide (or possibly restrict) write and read access to resources. How should this work?

Additive model

I think we'll need an additive model, which means that parents can only add permissive rights to resources. This helps to keep performance decent - if anywhere in a tree we see that the correct grant is present, we can execute the command. We don't have to evaluate the entire tree. This does, however, mean that it will not be possible to prevent children to be more restrictive than parents. There are situations where this will feel awkward. For example, when dealing with comments on something. We might think of comments as being children of some parent commnt / thread, but we generally don't allow the OP to get edit rights to all its comments.

Properties

• Have a read and edit array containing Agents (maybe groups later on). These can be present on any resource. They are checked before returning a resource or applying a commit.

from atomic-data-docs.

Folders

Even though any resource can be a Parent, we might want to use folders, too. These might contain items that are foreign, so they are not necessarily strictly children of the Folder.

from atomic-data-docs.

I've been thinking about bidirectionality. For now, childrens describe their parents - but parents do not have to set their children. Parents can add rights, and in that case it only makes sense if children describe their parents, not the other way around. Otherwise, we could have some new resource that maliciously pretends to be the parent of a child, and then gains write rights to something. Not good, so we need children to be in charge of who their parents are. Yay, children!

But... Sometimes, we need to find children by navigating parents. For example, when opening the navigation sidebar in the Atomic Data Browser. Currently, we calculate the children at runtime, basically by querying the database. This has some performance cost, so at the moment we only do this for Drive resources (which are the top level items that appear in the sidebar). This, of course, does not cover all usecases for finding children, because all resources can have children!

I think we have a couple of solutions:

Use a collection / endpoint for finding children

If the front-end needs to know who the children are, simply create a Collection and perform the query. This means front-ends will need to have logic for doing this.

Only allow Drives / specific resources to have children

This means - treat Drives like folders in a Filesystem. Only these Drives / Folders can have children. The /commit handler should check if the parent is a Drive, and if it is not, it will error.

This is kind of limiting, because it often feels logical to have a parent relationship to something that's not a folder. Although, to be honest, I can't really think of important usecases at this moment. Hmm.

from atomic-data-docs.