Skip to content

Instantly share code, notes, and snippets.

@pfrazee
Last active August 11, 2016 16:52
Show Gist options
  • Select an option

  • Save pfrazee/804dd883948c38dddfc7b76c2a3907cf to your computer and use it in GitHub Desktop.

Select an option

Save pfrazee/804dd883948c38dddfc7b76c2a3907cf to your computer and use it in GitHub Desktop.

A shared file & object store for Beaker.

Requirements:

  • Applications need to share files & data with each other. For instance, you want to be able to share your contact list between apps. (Think about the ways that phones share data - it's the same story here.)
  • Userdata needs to persist outside of a given application. If I decide to stop using ContactsPro2000 then I still want UberFriends to have my contact list.
  • Ideally, users won't be interacting with files. We may still need that, but file-managers never make anybody smile. This isn't a hard requirement. If nothing else makes sense, we'll use a file manager.
  • Applications need to not clobber or corrupt each others' data. They need to work together.
  • We need some shared semantics, to handle interop. Solid, IPLD?
    • For that matter, I dont think it quite works to just have a bunch of files sitting around. We need smarter queries, like, "give me all the user's contacts." So, we need metadata
  • We need disk-usage quotas
  • We need permissioning
  • We need interactions with Dat & IPFS. "Make this folder a Dat/IPFS archive?"

Based on that, here are the features/ideas kicking around in my mind:

  • Build it on Sqlite.
    • This would handle the metadata and querying functions.
    • Even better would be to have data rows (not just metadata rows), because SQL is, you know, a GOOD DATA SOLUTION ! If there was a clear concept of, "which file does this row belong to," then there'd be a smooth conversion from tabular-form to file-form, and back. That conversion is valuable, because files are essentially groupings of data that should move around together.
    • @ogd Sqlite has convenient facilities for limiting disk-usage, which is why I'm tempted to store blobs in it, despite the performance loss. We'll see.
  • Atomic, and/or transactional, operations. Not a posix interface, which isnt atomic.
  • FTS and general indexing facilities.

BeOS had some kind of awesome metadata heavy FS. I should probably research it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment