I'm liking the idea of basing something around sqlite. Specifically, I'm liking the idea of interoperating with SQLAR which is a trivial archive format layered on top of sqlite by the authors of sqlite themselves.
SQLite is well known for its portability, speed, compactness and robustness. Now, by retrocomputing standards "compactness" is a relative term - we're talking half a megabyte or so of object code, but for modern platforms that's negligible.
One way sqlite wins over things like TAR and ZIP is the versatility of being able to augment the data structure with almost anything else you care to add - whether in new tables, or as extra columns in an existing table. Another is that it has good support for changing the content rather than merely creating and reading archives.
Also, the sqlite flavour of SQL is a standardised and mature textual representation for data.
I can see a few interesting ways such techniques could be used:
- Create an sqlar file as a repository for an entire hierarchy of Acorn files with all their metadata
- The same, but also include a file server's user database, or similar stuff.
- Create an sqlar file as an metadata-and-optional-compression wrapper around a single Acorn file.
- Create an sqlite database under a standardised (probably hidden) name in a directory, to store metadata for that directory's files
- Traverse the directory hierarchy upwards until you find such a file, which can store metadata for an entire subtree
- Associate a single textual SQL statement with a file, either by putting it in an adjoining file or by putting it in an extended attribute
- Disc titles
- *OPT4 settings
- Information about where files came from (DFS, ADFS, Econet fileserver, Linux, etc.) and sub-categorisations (Atom v. Beeb DFS, SJ Research v. Acorn fileserver, Linux foo.c => foo/c v. foo.c => c.foo, etc.) to allow more informed strategies for dealing with the other metadata. For example, being aware that the middle-order bits of a load address are inferred for a DFS file, or that bit 3 of the attributes means Private not Locked on an SJ Research fileserver.
- The capacity to represent RO3+ image files as either the binary object or the unpacked directory structure they contain.
I also realised one minor wrinkle in SQLAR: for each file it has a blob of data and a size field. If the size is greater than the length of the blob, it is assumed that the file is compressed. However, it actually assumes this if the size is unequal. It would be good if it were possible to represent a file by an uncompressed blob that is longer than the file, to leave extra extent for in-place expansion. Fixing this was a trivial one-line change to the SQLAR source code, but I'd probably want to get that change accepted upstream before letting the practice out into the wild.
So: good idea? Sucky idea? Worth thinking about some more?