└── Readme.markdown /Readme.markdown: -------------------------------------------------------------------------------- 1 | Relational File System, ongoing development version 2 | =================================================== 3 | 4 | 5 | ## Overview 6 | 7 | The Relational File System (RelFS) is a proposed new way to store files and represent knowledge. 8 | Although the hierarchical file model is ubiquitous, RelFS is intended complement or replace hierarchies as the preferred way to organize files. 9 | 10 | RelFS combines features from classic hierarchical file systems, relational databases, and content-addressable storage systems. 11 | Viewed in another way, RelFS takes the hierarchical model and removes undesirable features and limitations. Then it adds new features to support desirable use cases. 12 | 13 | The RelFS proposal defines: 14 | 15 | * The concept of immutable, hash-addressed files 16 | * The basic operations supported by file repositories 17 | * How to define schemas to represent metadata 18 | * How metadata values are serialized to / deserialized from bytes 19 | * Sketches of practical metadata and practical queries 20 | 21 | The RelFS proposal does not cover: 22 | 23 | * The meaning of metadata types and values 24 | * What application should read/write what metadata 25 | * Repository storage formats and low-level details like file packing, fragmentation, delta encoding, indexes, etc. 26 | * Multi-user concerns such as file permissions, storage quotas, etc. 27 | * Administrative details such as replication, fault handling, etc. 28 | * Support for file change notifications, publish/subscribe, etc. 29 | 30 | 31 | ## Background and motivation 32 | 33 | The RelFS proposal was born out of Nayuki's frustration with trying to organize personal files into hierarchies. 34 | The most general way to store information is the hierarchy of directories and files, and this mechanism is what every major operating system provides. 35 | However, this ubiquitous hierarchical file model is full of undesirable features: 36 | 37 | * Contrast with hierarchical file systems 38 | * Names suck, paths suck, length limitations, no structure (e.g. integer, fields) 39 | * General metadata formats are brittle 40 | * Brittle references 41 | * Dependent metadata 42 | * Poor unions 43 | * Poor deduplication 44 | * Poor sharing 45 | * Poor propietary media libraries 46 | * Different metadata per file format 47 | * Nayuki's first article on this topic published in Mar 2017: [Designing better file organization around tags, not hierarchies](https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies) 48 | * Inspiration from Git version control, Danbooru image board, BitTorrent file sharing, eDonkey2000 hash links, IPFS, Perkeep (formerly Camlistore), relational database model 49 | 50 | 51 | ## RelFS main concepts 52 | 53 | * Files are plain blobs 54 | * Files have no inherent name 55 | * Files are immutable 56 | * Files are addressed by hash 57 | * Metadata can reference nonexistent files 58 | * Metadata can have metadata 59 | * Everything is a file 60 | * Location is independent of queries 61 | 62 | 63 | ## Notes about RelFS 64 | 65 | * Repositories are mutable 66 | * Versioning has many possible incarnations 67 | * File system implementation can store more copies 68 | * Can implement stuff like file permissions, even hierarchies 69 | * Interfaces poorly with path-based systems, but also these systems don't take advantage of hash features 70 | * Is not a graph database, but is more general 71 | 72 | 73 | ## License 74 | 75 | Copyright © Project Nayuki - https://www.nayuki.io/ 76 | 77 | Licensed as Creative Commons Attribution-ShareAlike 4.0 [(CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/). 78 | --------------------------------------------------------------------------------