I think I figured out how to solve one of the problems. A big problem is dealing with uploads on a busy system. On an admin-only, or a few editor systems, it's not much of a problem. But on busy systems it would be.
Assumption #1 for the first releases:
This is a postcards/picture-post program where user-uploads are anticipated (rather than a gallery or an admin-only upload situation). (Gallery management features will be added later once the parts work).
I propose:
1) give each user a directory <%username%> (this means restrictive usernames)
2) All a users uploads go into that directory, and thumbnails are in <%username%>/thumbnails. This allows one /uploads directory, or /uploads/a, /uploads/b etc type divisions.
3) files are given the LinkID as their stored name. A user can see their aborted files if their directory has un-attached files in it, and figuring out who an aborted file belongs to is then really easy.
4) Not every user will upload files. Not every user will have a directory. If a directory exists for that <%username%> a user has uploaded files.
5) This will dove-tail with the 'attachments' modification when/if Alex/GT decides what that will look like. Attachments can go into one central area or into <%user%> or <%category%> directories. More functions will be added with the "gallery maintain" routines, but we have to start somewhere.
6) Image/physical-disk layout will most likely _not_ resemble the presentation-interface in any way. It's more and more obvious that this is the way to go, and if you want the disk to look like the interface, just upload it that way, but the interface will not be limited by the disk-layout.
Comments... Remember, this system has to be scalable, so what might seem like over-kill on a site with 100 or even 2000 links, will be a necessity on a site with 20,000.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
Assumption #1 for the first releases:
This is a postcards/picture-post program where user-uploads are anticipated (rather than a gallery or an admin-only upload situation). (Gallery management features will be added later once the parts work).
I propose:
1) give each user a directory <%username%> (this means restrictive usernames)
2) All a users uploads go into that directory, and thumbnails are in <%username%>/thumbnails. This allows one /uploads directory, or /uploads/a, /uploads/b etc type divisions.
3) files are given the LinkID as their stored name. A user can see their aborted files if their directory has un-attached files in it, and figuring out who an aborted file belongs to is then really easy.
4) Not every user will upload files. Not every user will have a directory. If a directory exists for that <%username%> a user has uploaded files.
5) This will dove-tail with the 'attachments' modification when/if Alex/GT decides what that will look like. Attachments can go into one central area or into <%user%> or <%category%> directories. More functions will be added with the "gallery maintain" routines, but we have to start somewhere.
6) Image/physical-disk layout will most likely _not_ resemble the presentation-interface in any way. It's more and more obvious that this is the way to go, and if you want the disk to look like the interface, just upload it that way, but the interface will not be limited by the disk-layout.
Comments... Remember, this system has to be scalable, so what might seem like over-kill on a site with 100 or even 2000 links, will be a necessity on a site with 20,000.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
Image Gallery/Picture Post 4