This particular design asked for a program to centralize file access. Instead of having each program handle the specific location of the data files (on the hard disk or in FLASH or RAM), the developers decided that one program would handle it. Furthermore, file updates done by one program required that all programs using that file be notified. So instead of having each program notify each other, only one program would take care of the notification. That program was cleverly named “database”.
The API in the original design included db_read(), db_write(), db_update_notification(), etc., but a resource manager is an even better fit. The API was changed to the familiar open(), read(), write(), select(), ionotify() and so on.
Client programs were seeing only one path, /dbase/filename, but the files found in /dbase/ weren't physically there; they could be scattered all over the place.
The database resource manager program looked at the filename during open() and decided where the file needed to go or to read from. This, of course, depended on the specific field in the filename. For example, if the file had a .tmp extension, it would go to the RAM disk.
The real beauty of this design is that the designers of the client program could test their application without having the database program running. The open() would be handled directly by the filesystem.
To support notification of a file change, a client would use ionotify() or select() on the file descriptor of the files. Unfortunately, that feature isn't supported natively by the filesystem, so the database program needs to be running in order for you to test the operation.