* Robby Russell <robby@xxxxxxxxxxxxxxx>: > On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote: > > App needs to allow users to upload pictures. (jpg and gif), > > needs to create thumbnails of those pictures > > and to store thumbnails and full pictures. > > > > App needs to manage all those files - can be as much as 20K plus > > images. > > > > I think image file size, file type and image dimensions restrictions > > should be easy to handle by using $_FILES array and getimagesize > > function. > > > > The issues that I am thinking of and need suggestions about are > > > > 1) Storage and retrieval - File system sounds like a better choice > > over database. We are talking about 20 thousand plus pictures. > > I would do it in the database (PostgreSQL in my case). The speed isn't > going to be much slower if you keep things optimized. You can even cache > your images if necessary on the filesystem (for high traffic images). I have difficulty believing retrieving an image from a database will have similar speed performance as simply grabbing it from the filesystem... and if you're seeing a need to cache images on the filesystem anyways, that's certainly already an argument against it. > > 2) Thumbnails - Should I create those once and save it in a file when > > the image is uploaded for the first time. Looks like a faster option > > than creating them every time on the fly. > > I just recently finished working on a project where I knew that would > automatically create a thumbnail version of each image on upload... but > then I realized that I might one day want to change the default > thumbnail sizes.. so what I did was have it create a thumbnail on the > fly from the database. (this way I can control the thumbnail size in the > future). The speed difference was hardly noticed. I have done what I > mentioned above and am now caching images that get loaded frequently. Thumbnailing on the fly may have decent performance, but it *is* slower than simply serving up an image. If you doubt that, try surfing from a T1 connection some time (dial-up users may not notice the extra time required to generate the image, but those on broadband will). In addition, if you generate a thumbnail every time the image is requested, you're making your server do extra work -- even if you're caching oft-requested images. I understand the argument regarding a future change in thumbnail sizes. However, generating thumbnails on a filesystem of images is something that is easily scripted and can be performed on an as-needed basis. (ImageMagick is great for this sort of thing, and scripts in PHP using GD could also be used.) > > 3) Security issues - I believe I must have a world writable "666" > > permissions directory to keep images as users of the web app are > > uploading them. Does that create any security holes in my application? Depends on if you're on your own server or a shared host. One thing you can do even on a shared host is to make one directory 777 and then have PHP create directories within that; however, as noted by somebody else previously, someone else on the shared host could be malicious then and write over those directories. If you're on your own server or a dedicated host, give read and write permissions only to the web server and one or two groups. > The database will help you add a nice layer of security. If the OP is on a shared host, that is one of the rare instances I'd suggest putting uploaded information into a database -- and only if there's a liklihood of other clients on the server being malicious. However, in a shared host environment, if a user *does* do something malicious, you can usually complain to the service provider and get compensation. -- Matthew Weier O'Phinney | mailto:matthew@xxxxxxxxxx Webmaster and IT Specialist | http://www.garden.org National Gardening Association | http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
