44 lines
1.5 KiB
Text
44 lines
1.5 KiB
Text
I like the idea of a layered architecture, with a db layer that manages
|
|
filesystem i/o.
|
|
|
|
|
|
# API
|
|
|
|
* Read a filesystem object into a struct Issue (e.g. `ent show`)
|
|
|
|
* Write a whole struct Issue into a filesystem object (e.g. `ent new`
|
|
or `ent comment`).
|
|
|
|
* Write a single field from a struct Issue into an existing filesystem
|
|
object (e.g. `ent state ISSUE Done`).
|
|
|
|
On write operations, the git commit message should be meaningful to
|
|
the application. Maybe that can be done generically by the db library,
|
|
or maybe the application needs to supply the commit message.
|
|
|
|
|
|
# Design
|
|
|
|
A filesystem stores two kinds of things: directories and files.
|
|
A directory contains files, and other directories.
|
|
|
|
Git stores two kinds of things: trees and blobs. Trees contain blobs,
|
|
and other trees.
|
|
|
|
Maybe this DB tracks two kinds of things: databases and key/value objects.
|
|
Databases store key/value objects, and other databases.
|
|
|
|
Some things we'd want from this DB layer:
|
|
|
|
* Filesystem objects correspond to structs, like how we have each struct
|
|
Issue in its own issue directory.
|
|
|
|
* Structs are nested, like how struct Issue contains struct Comment
|
|
|
|
* Some fields are simple types (`author` is String), some are
|
|
less simple (`timestamp` is chrono::DateTime), some are custom
|
|
(`state` is enum State), and some are complicated (`dependencies`
|
|
is Option<Vec<IssueHandle>>, `comments` is Vec<Comment>)
|
|
|
|
* Filesystem objects are optimized for getting tracked by git - minimize
|
|
merge conflicts.
|