This is a revamp of the organization of the MediaFiles, Projects, and Libraries. This project aims to almost completely re-define the heirachy of the major organization units in ARLO to facilitate more straightforward organization and effective sharing of data amongst users.
A brief overview of the current organization is at Data_Hierarchy, but we'll step through the changes incrementally below.
- 1 Proposed Changes
- 2 Heirarchy
- 3 Sharing
- 4 Considerations
- 5 Implementation
In the Beginning...
... developers created the concept of Libraries, a collection of various MediaFiles and Tags. The Library was the fundamental work unit in ARLO. A Library consisted of a list of MediaFiles (typically audio recordings) and contained all of the Tag data. Various functions operated on the Library such as Supervised and Unsupervised searches.
Libraries were contained within Projects. The idea was that there may be Project-wide functions (similar to the searches) that would span multiple Libraries, but this was never realized. The Project remains an unnecessary hierarchical member in this model.
While the same MediaFile could be used in multiple Libraries, setting this up was cumbersome, especially for large sets.
Trimming the Fat
So, why not drop the Project from the hierarchy? It serves no useful purpose really, and just adds complexity.
But wait, Library is such a horrible name for this... if only there were a better term... maybe we could call it a Project?
Now, say we want to start a new Project using all of our same MediaFiles... all 30,000 of them. Manually adding all of these to a new Project would be a pain.
Instead, what we need is a way to group these. In iTunes, one can make Playlists to create arbitrary lists of songs, so let's create Playlists. This can be any logical (or illogical) grouping of files, such as by genre, subject matter, music/poetry, etc.
(Full disclosure, I hate this term... I mean, we're not playing anything. but the analogy fits, it's easily relatable to established models, and most importantly, I have nothing better to propose.)
As with a playlist in any media player, a MediaFile can appear in multiple Playlists.
Within the Project, we want a way to choose what files we are actively using. In the existing model, we have the notion of Active / Inactive files, but this is poorly implemented, hard to manage, and doesn't work well when multiple users are trying to choose their own active set at once.
Instead, we'll create WorkSets. This is a subset of all of the files within a Project. When we run a task such as a Supervised search, we can choose a WorkSet rather than performing the search on the entire Project at once.
While we're at it, let's go ahead and give the user's set of MediaFiles a descriptive name... This will be the new Library. This is simply ALL of the user's MediaFiles.
MediaFiles and Library
MediaFiles will be uploaded by users, and initially only they will have direct access to these. MediaFiles alone will exist as a standalone object directly unusable elsewhere until they are added to PlayLists or Projects.
The entire set of a user's MediaFiles will be referred to as their Library (note that this is a change from the prior Library concept).
This is similar to the iTunes concept of your Library, a collection of all of your media.
PlayLists are a list of MediaFiles. PlayLists can be shared with other users, giving them readonly or edit access (the ability to add or remove files).
Continuing the iTunes concept, a user can create multiple PlayLists of sets of songs. Songs may be in multiple PlayLists.
The prior concept of a Project and Libraries are being thrown out. Previously, a Project contained multiple Libraries. However, the Project concept was mostly unused, and most work was done at the Library level.
The Project will become the primary workspace, with the Library hierarchy being removed and all previous Library functions being moved to the Project.
Projects will hold the TagSets (and hence Tags) and TagClasses.
A Project will contain 1 or more PlayLists. The unique set of all of the MediaFiles within these PlayLists will comprise of the Project Files.
- Should we also have the ability to add individual MediaFiles to a Project, without adding them to a PlayList?
A WorkSet in a Project is a subset (or all) of the Project Files. This is the unit upon which actions will be taken (e.g., Supervised / unsupservised Searches). The WorkSet replaces the prior notion of Active / Inactive files.
MediaFiles and Library
MediaFiles are always Read Only. The file owner can delete the file only if they are not in any PlayList or Project (of any user).
The owner of a PlayList always has full read/write access (can add or remove files). Additionally, the owner can assign default permissions for the Playlist, as well as permissions for individual users.
The owner of a Project always has full read/write access. In addition, the owner of a Project has full read/write access to ALL data within the Project, regardless of permissions individual users may set for contained data (i.e., TagSets).
The owner can assign default permissions for the Project, as well as permissions for individual users.
- Read Permissions
- Visualize files
- Write Permissions
- Create TagSets
WorkSets will by default inherit permissions from the Project they are in. Additionally, users can set explicit default or per-user permissions.
TagSets will by default inherit permissions from the Project they are in. Additionally, users can set explicit default or per-user permissions.
- Read Permissions
- View existing Tags, for example in file visualizations or the Catalog
- Run seaches (e.g., Supervised/Unsupervised) and save the results to this TagSet
- Write Permissions
- Create new Tags or Delete / Modify existing Tags
- Should there be a distinction between Write / Create / Delete access?
- Read / Write access is vastly easier to implement and manage (from the User perspective) but is far more limited.
- For example, say a Project has been shared with a user. With simply Write access, they would need to have write access to the Project to create their own TagSet, but this would then mean that they have the ability to delete / modify TagSets to which their access has not been explicitly revoked.
- Instead of inheriting permissions from the parent in the hierarchy (for exammple, TagSets from Projects) should explicit defaults be required on every data object?
- Should a user always be allowed to create a TagSet or WorkSet in a Project, regardless of whether they have write access? If they have read-only access, they can't modify existing data, so is there any harm in allowing them to create their own?
- Should the owner of a Project always have read or write access to all data that other users create, regardless of their permissions settings?
The implementation of this will proceed hopefully in a few separate, smaller steps:
- First, from the current hierarchy, the Project layer will be removed, and Libraries will become the new Project. With the exception of a few individual cases that have multiple Libraries per Project, this should not largely change the existing data. Likely, these Libraries will become their own new Project.
- Hopefully we can implement the new PlayLists / WorkSets models without changing the current sharing scheme. That is, implement the new hierarchy, keeping the existing Project level sharing.
- Finally, start adding granularity to the permissions, adding more than just the Project level sharing that we have now.