Why a graph instead of the application-specific SQLite database?
I want Pikov to be flexible to more use cases than just what I come up with. This means adding "columns" or properties to the Frame and Transition objects to support new logic. A SQLite table isn't well suited to wide, sparse tables.
Why JSON?
We could have efficiently represented a graph in SQLite, and there are still benefits to doing so, but I think JSON is a better starting point because it is more compatible with existing version control systems. I felt a bit nervous checking in a big binary blob for the the "gamekitty" example. Now there's a binary blob for images, but frames, transitions, and other logic are represented in JSON, which is more compatible with git's line-based text diffs.
Eventually, I do want to support other serialization formats, like SQLite, Firestore, LevelDB, and Hyperdrive. Since the graph structure is quite simple and flat, I believe it could work well in each of these.
Why a graph instead of the application-specific SQLite database?
I want Pikov to be flexible to more use cases than just what I come up with. This means adding "columns" or properties to the Frame and Transition objects to support new logic. A SQLite table isn't well suited to wide, sparse tables.
Why JSON?
We could have efficiently represented a graph in SQLite, and there are still benefits to doing so, but I think JSON is a better starting point because it is more compatible with existing version control systems. I felt a bit nervous checking in a big binary blob for the the "gamekitty" example. Now there's a binary blob for images, but frames, transitions, and other logic are represented in JSON, which is more compatible with git's line-based text diffs.
Eventually, I do want to support other serialization formats, like SQLite, Firestore, LevelDB, and Hyperdrive. Since the graph structure is quite simple and flat, I believe it could work well in each of these.