Re: [Social-mediagoblin] Tahoe-LAFS as a document-oriented database

[will kahn-greene]

On 04/10/2011 11:02 AM, Christopher Allan Webber wrote:
>
> Or we could do:
> 
> /media/USER_ID/ENTRY_ID/${RANDOM_UUID}-filename.png
> 
> always, but that means that if someone wants to wget the file, they'll
> have a bunch of ugly stuff ahead of it for no good reason, which is sad.

I think we should go with this for the file system.  There's no reason I
can think of that mediagoblin can't recognize the :

wget http://mediagobl.in/media/USER_ID/ENTRY_ID/filename.png

situation, notice that it's not ambiguous since there's only one thing
with that filename, and do the right thing.  That's something we could
add support for later.

So my vote is go for simple and extendable now and we can change things
later if need be.

Also, I don't think we should expect any of the decisions we're making
now to be final until the end of time.  Not sure if that's been
mentioned yet or not, so there you go.


> [snip]
> If we always tack on a uuid somehow I guess it will prevent this, when
> direct linking to the file, that is.  I'm fine with every "different"
> file uploaded always having a unique filename.
> 
> But one thing I *do* want to be changable is, say I upload:
> 
> http://mediagobl.in/cwebber/work/cats_pajamas/
> 
> I want, and *must* support, the ability to make a change to the image
> shown here.  Not necessarily the hotlinked image, but if I realize I
> accidentally made my cat's eyes purple, I must have the ability to
> correct them to green if I want to.
> 
> That leads to an interesting question: what happens to the old file, if
> I'm replacing it with a new one?
> 
> One solution is for us to support "old revisions" of the main file.  If
> I change the file, I might be able to do in the user interface:
> 
>    ☑ Keep old file revisions
> 
> ... which will be checked by default.  That way my main "display" page
> can have the content change, but the storage system won't have the file
> change.
> 
> I could really use some direction on this!  Zooko, Asheesh, Will, and
> any others with relevant thoughts: please weigh in.

One of my use cases for this system is to support a workflow for
creating, pushing, and versioning mockups for stuff I work on.  Thus I'd
also like revisions.  Having said that, I could adjust my dream mockup
workflow to live without them, too.

Perhaps for now, we should assume we're keeping all revisions.

Also, it occurs to me that the only thing that makes a revision a
"revision" is that there's some data on the entry that links a bunch of
files together.  From the "filesystem" point of view, it's probably
easier to think of it as just a bunch of files.

Later on, we can make "keep revisions" a setting on the account-level
and the file-level and also allow users to prune existing revisions.  Or
whatever.

Does that help at all?

/will