From: Edward W. <Edward.Wildgoose@FRMHedge.com> - 2002-02-27 15:24:23
|
All good points! However, whilst I am NOT a fan of arbitrary limits, I think 10,000 = images in a single gallery sounds like a reasonable one, it would = certainly be very difficult to browse 10,000 images over the web. I = strongly suspect that you would want to use at least a few = subdirectories. (Does this reset the directory limit in most common = filesystems?) I think that the basic design still flies (might be better?) if you do = without the directories, you then need to name each file in a certain = way so that you can see derived images belong to the main parent image. = Also so that any script tools can move the image and derived images in = one batch. Good point on the Symlinks. Revert to suggestion 2 to create a symlink = effect in software, ie just have "pointers" to the orig file. With regards to scripting. I think that we both agree that we would = like some scripting tools to do things. Whether the storage is DB, or = filesystem makes no odds, we still need to do batch operations. = However, if everthing is in the DB you NEED scripting tools, if the = storage is filesystem, then I can point Photoshop at the image dirs and = do a batch resize operation to save space (or any of the thousand other = image tools which exist today...Gimp, etc) File system has one other advantage for me and many other people. I = have a ton of pictures that I archive on my main machine, filed in some = sort of hierarchy, eg, year, subject, etc. I want to occasionally = jiggle these around, print a few out, and also have them shared via WWW. Any thoughts? Ed -----Original Message----- From: Anthony Moulen [mailto:ajm...@mo...] Sent: 27 February 2002 15:01 To: Edward Wildgoose; gal...@li... Subject: Re: [Gallery-devel] Image SubDir Modification On Wednesday 27 February 2002 04:21 am, Edward Wildgoose wrote: > No, no. There is nothing here that you can't do with a directory = tree, > even on Windows. Go back to the original suggestion: > > $GalleryRoot has two sub-dirs Gallery1 and Gallery2 > under Gallery 1 there are some sub-dirs, one for each image, eg = Image1, > Image2, etc (these all have meaningful names in practice) All filesystems have a limitation of how many directories can be = attached to a=20 directory root, with 10000 images you would have 10000 directories, on = some=20 smaller file systems (fat16 perhaps) you may have exceeded your limit. = Now=20 it is understood that fat16 isn't going to be used in a gallery since = there=20 are other limitations such as filename length and such, that makes it=20 impractical. But you need to consider that there is a real limitation = to=20 your model as far as connections work. Also you are taking up diskspace = to=20 build an image dir for each image.=20 > > OK, now in Gallery2 you want to include some images from Gallery1, so > symlink the directorys into Gallery2...! But what about windows...! = Well, > newer versions (Win2K+) have symlink equivs, but - OK, create a = software > symlink, ie if Gallery encounters an Image subdirectory which contains = no > files, except one called "Redirect.Gallery1/Image2" then you follow = the > link and pull out those images as though they were local! Very simple = and > straightforward. Symlink is possible in Win2k and above, but it may not be an equivelant = to the=20 UNIX symlinks. Also there are known security problems with Win2k = symlinks=20 (there are security advisories out there about it). Anything that has = the=20 potential to affect the security of the OS should not be used within the = construct of a networked tool like this. Imagine if someone were clever = enough to symlink the system directory over, and could thus get to it = via the=20 web.=20 -- SNIP --- > (The symlinks are going to break if you move stuff manually (except = under > windows interestingly enough!), but I think this is the price to pay = for > going outside the tool. It would certainly not be impossible to = create > shell scripts that also check for symlinks and update those also. You > couldn't do this at all if you used a database for everything - I am = happy > to hack the tables in SQL, but the rest of the world is going to need = a > tool. Perl with the MySQL DBI is a perfectly viable scripting tool. And the = tools=20 should be something that is considered when designing a robust DB bound=20 system. Symlinks are a bad model, they simply aren't allowed in so many = environments that it isn't a good idea. Look at Apache for a moment, = the=20 default for personal directories is not to follow symlinks. This is = done for=20 a reason, Security. =20 This system must be designed with at least a modest amount of security = in=20 mind. And it must not impose an insecure model on the OS level. Right = now=20 the system it self is fairly safe, sure it can eat up diskspace like = there=20 was no tomorrow, but as long as you have partitioned off your web data = from=20 your OS the worse that could happen is you run out of space for more web = pages. Add symlinks and someone silly enough to run Apache as root and = you=20 have a natural disaster waiting to happen. |