I had an interesting idea the other day and had to try it out. It occurred to me that you could do a pretty decent job of modeling a Frontier object database as a GitHub repository and vice versa. Then you'd be able to use GitHub to coordinate work on a tool.

And it would work the other way too. You could use Frontier scripts to do stuff with any random GitHub repository.

I think either way it was worth taking a look at.

So I did two things.

Here's the respository.

I haven't written the scripts yet that extract the bits out of the repo and put them into the object database.

But I wanted to put the idea out there.

Honestly, not expecting much if anything to come back.

But this is just a blog, and just a post on a blog.

Nothing earth shaking.

But this might go somewhere and if so this is where it starts.

Very interesting. Coincidentally, a few weeks ago I was thinking about how I'd implement the Frontier object database were I doing it from scratch.

I wouldn't want to write something new. So, what, then? SQLite, LevelDB, Kyoto Cabinet? None of the above -- I'd use the file system.

My rough design was something fairly obvious: tables are folders. Objects are files. And each table gets one special file for scalars. (I'd want to use JSON for the scalars file, probably, but JSON doesn't have a date type. Not sure what I'd do.)

Machines are easily fast enough these days (especially with SSD drives). A few more benefits:

A weird -- but possibly interesting -- side effect is that you could treat any folder on your hard drive as an object database.

I really like Brent's idea and would like to try it out to see how it performs and where I'd hit deal-stoppers. What's the best way to get started?

I want to be able to access this object database from anywhere. From any language, running on a client or server, in browser, anywhere.

If you wanted to start the bootstrap, what would be the first code you'd write, in what language, and how would you get to the disk, through which API?