[ansel] Ansel::listGalleries()

[Heath S. Hendrickson]

> I started to mess with this & ran into a snag.  Images are stored in 
> the vfs in
> a directory structure that reflects the gallery tree.  If we were to 
> move a
> gallery, we'd have to move the images in the vfs, too.
>
> This, plus the idea of making an image "bucket" with pointers makes me 
> think we
> should re-evaluate the vfs directory structure.  I though of just having
> everything in the .horde/ansel directory, but that would be a lot of 
> data in
> one directory.  Another thought was to have .horde/ansel/full,
> .horde/ansel/thumb, and .horde/ansel/screen directories.
>
> Any other thoughts?
>
I was thinking of the problem of the image bucket as well.  Imagine if 
you had an Ansel installation that had 10,000 images from multiple 
users...  You'd hit the filesystem limit for files in a single directory 
for windows and on linux you'd just take a long time to do anything in 
that directory (for ext2). 

One suggestion that I saw was to store the images in a hashed 
structure...  The only way to get at least a failry uniform 
distribution, though, would be to use the objectID or some other 
assigned value.  Anything else is too likely to be weighted unevenly 
(filename was one suggestion, but most cameras use the same naming 
convention for images P####, CRW####, etc).  You could do it by date 
(say day+month+year), but again, that would still have a high likelihood 
of being skewed to periods of large uploading and periods of no uploading. 

One question I have is, is an objectID ever re-used?  If I upload an 
image and it gets ID=500.  then a month later I delete it, will ID=500 
ever be reused?  It would actually be ideal if it were for the purposes 
of the a hashed image bucket scheme... then you would have a very even 
distribution. 

Try setting it up with buckets of 100 or something similar (assume that 
most images are anywhere from 400kb to 10MB originals).  You can even 
further divide it up into 3 main buckets (full, screen, thumb) and then 
divide each of those up into incremented buckets 
(full_0-99,full_100-199, etc.).  This way you might even be able to 
avoid using the "_full", "_screen" and "_thumb" extensions on the 
filenames (if you wanted to, that is).  Heck, why not even make it 
something an admin can configure (Set max number of images stored per 
VFS directory).  This would only apply to the filesystem VFS, though.  
There's no need to segregate the SQL based storage.  It's all in the 
same table anyway.


    /full
       /full_0-99
       /full_100-199
       /full_200-299
    /thumb
       /thumb_0-99
       /thumb_100-199
       /thumb_200-299
    /screen
       /screen_0-99
       /screen_100-199
       /screen_200-299

Just my thoughts.

h