It’s been quite a few busy days for me. I’m here at PyCon for the weekend, and there seems to be a cool arrangement (beds with pillows, wifi etc) for people to work on their personal projects, and also for those up for some weekend hacking!
Anyway, I spent a good chunk of the day planning possible changes to Glittery’s file storage concept. The previous model relied on a Glimage model that belongs to Projects, but that seemed to turn out as a barrier when I tried creating Glimages through SVG-edit, and also when I spent time implementing the fork project function (Similar to GitHub’s).
I guess we’ll now drop the Glimage model. We can fetch the Glimages through
image names commit SHAs that we pass in the url. Although Glimages can no longer be individually private; we’ll go ahead and allow projects to be private (not accessible to anyone other than the author).
The only problem I can directly see coming up is the comments attached to the glimages. I have a workaround for this, although I’m thinking of a better one. Comments are served as polycomments, so we’ll just play around with the type and type_id attributes.
So now the flow happens this way –
- User signs in and creates a new project (possibly with a glimage upload)
- We assign a non-bare repo for the project, and clone a bare repo from it.
- Every time a new file is added or updated, we commit to the non-bare repo and immediately push to the bare repo.
- When viewing glimages, history and current status can be obtained via the grit API.
- Pushes made from forked projects will go to the parent repo’s bare-repo and changes commited to the non-bare ones.
This is the vague idea as of yet. Emily’s been saying something about post-receive hooks that I haven’t understood anything about. Will probably check that out tonight and I hope this will be a refined blogpost by tomorrow (with handmade graphics 😉 )
Update – I’ve added a post about how the comments will now be handled here.