Previous Entry Share Next Entry
Are you using photos in Querki?
jducoeur wrote in querki_project
That is, have you used the "Upload a Photo" Action?

I'm actually hoping that the answer is "No". One of the major enhancements coming in the next couple of months is doing Photos *right*, and based on what I learned from the Wedding Space (and the requirements of the upcoming Spaces), I'm planning on a ground-up rewrite of the mechanism -- probably not even doing the storage ourselves any more. Once I'm done, it should be a very important, powerful new tool for you to use. But I'm hoping to avoid having to port the existing photos into this new mechanism -- if nobody is using them except for my original Wedding Space (which at this point is sacrificial), then I don't think I have to do so.

So please speak up if you are currently using photos, and if you aren't doing so yet, please don't do anything important with the mechanism. Thanks...

  • 1
Not using them, but curious as to what you mean by 'doing them right' vs. 'what you do now'.

At the moment, photos are "Attachments" -- full-fledged, heavyweight Things. They are also being stored in the MySQL database. As I've looked at the likely usage, I've concluded that both of these approaches are dead wrong.

First of all, photos shouldn't be Things, they should be *Values*. Precisely speaking, we should really have a new Type, called Photo. You should be able to define a Property of that Type, like any other, as ExactlyOne, Optional, Set or List of Photo. When you _edit that type, it should show a button that lets you upload or (if available) take a photograph. Rendering the value produces a link that shows the photograph. (With functions to access different resolutions.)

As for storage, putting the pictures in MySQL is terrible, but I always knew that would be the case -- it was a stopgap hack for the Wedding Space. Aaron and I have talked it through, and we're gradually concluding that the most sensible option for the time being is probably to store them in, and serve them from, Amazon S3. It'll cost a bit of money, but it saves us from having to deal with the file-storage issues for the time being. It does mean that we'll have to impose limits on the number of photos allowed per user, but that was always going to have to be the case -- we aren't a true photo-sharing service, and for now our economics aren't optimized for that. (I suspect we will also limit photos to about a megapixel for the time being, for the same reasons: we are optimizing for in-page web display, rather than image sharing.)

All of this is likely to go in fairly soon: my next major Use Case is building the household Inventory Space for Lochleven, and IMO photos are a requirement for a good inventory-management app. Hence the immediacy of the question -- this is all likely to happen by July...

*nod* Let databases and file systems each do what they are good at.

Moodle has an interesting approach for images (and all files). It takes a hash of the file, and stores it under that name, making managable buckets based on the hash. So if the file hash is 1234567890abcdef, and it is a png file, it would get stored at (dataroot)/12/23/1234567890abcdef.png

And then all references and access to the file go through a db lookup. This let's them deduplicate, as hash collisions are virtually nil, so if a hash matches an existing file, it's a dupe. Plus, they can continue to enforce access restrictions and rights by enforcing those on the database references. If you don't have rights to the file, you're not going to get to look it up in the db. And only the app has direct access to the datastore, and if you do somehow get access to the data store, you can't go looking for a specific file (mygradeshere.xls sort of thing) as it has been stored by hash, which you'd only know if you already had the file.

But the only limit on file sizes is whatever is imposed by the server's PHP max file config.

Edited at 2014-05-15 02:42 pm (UTC)

It's a reasonable approach, somewhat similar to git, and I could see us going that way eventually. But for now, file storage is low-priority -- that's already a crowded space, and I have little desire to wade into those fights...

(Deleted comment)
Okay, cool -- thanks...

  • 1

Log in

No account? Create an account