Open jacobhinkle opened 12 years ago
I agree that short description belongs to metadata, but I think things like session name, etc. should be treated as part of the "resource name". I'm thinking that a hierarchical naming scheme (like filesystem paths) is the way to go, and that things like sessions, etc, should all be left to conventions inside this hierarchical scheme.
In the end, imp is something like a specialized filesystem, so I think it's fine to look at that space for inspiration.
And yes, mtime should be there.
I like this. It would make snapshotting the data to disk super simple too. There's always a choice between tagging and heirarchy though, and if you try and support both it seems like it becomes a headache sometimes. I doubt we'll be mining this crap too extensively though so a full-on label-based solution is probably just a waste. i vote FS-style heirarchy with attributes (metadata).
If we choose to serialize on a backend like MongoDB, hierarchical paths will make our life easier too. MongoDB stores everything in a single tree, and I think we can create indices on tree-like queries (foo//bar/ for example)
oh that's nice. queries could be nice. In fact setting it up like this we could make a fuse filesystem! only a little joking. Ok so I think it's settled we'll use a heirarchical model for resources and that'll be our unique ID.
In addition to holding metadata for individual chunks of data like name and short description, we should hold metadata for each "session" (call it workspace or whatever) including an mtime which gets updated same way a directory mtime is when any member is updated. Not sure how to implement authentication at all, but when we do we will want to have varying levels of permissions for each workspace probably.