folders
The new rules introduce folders, as opposed to the one common root we have/had. This causes several changes in the way we talk about files. A file /foo/bar can exist both in the images folder and in the videos folder. This gets even more complicated when we allow for nested folders. For example /images/foo/bar could be a file in the images folder mounted at /images/ and in the all folder mounted at /.
This document describes the way this can be handled; in particular in the referee; and how it could be stored in the database so that plugs drivers can access and update metadata of a given file.
The referee has access to the configuration. When it receives an update it needs to know a couple things about the file. It needs to know the folder in which the update occurred, the file's path in that folder and the metadata. With this information it can figure out which drivers it needs to forward the update to.
In order to figure this out the referee must take into account the fact some drivers might be bridges between two folders. This happens when folders are mounted into another folder on a file-system. In theory we could forget about this and let the drivers do the job of re-notifying us when an update in one folder triggers an update in another but this would be slow.
The basic algorithm, illustrated bellow, is a simple recursive search for connected folders. This is possible because we consider the path option in a service/folder entry in the configuration to be reserved for use with file-system like paths and therefor usable to infer folder hierarchies.
In this example the laptop's local storage serves as a bridge between the all and images folder, causing an update in the images folder to also be sent to services using only all such as server.
A given driver only gets one update even if it has multiple folders containing the file. If this behavior is not desired it can easily be changed. One advantage of not having multiple notifications is we wont trigger multiple file transfers.
The database needs to offer two mappings, one mapping (folder, path) combinations to fids, the other mapping fids to metadata. This way it is easy for anyone to get a hold of a file's fid and the metadata is still shared between all folders which is good. (At least we think so!)