I'm easily sidetracked. I admit it.
But, I came across a program I had looked at before, and this time, was bitten to buy it for a number of reasons. The major one (besides mis-interpreting what it offered) was it seemed to be built on top of a links 2.0 (flat file) shell. Looking at the code, it's not, really. But it's using a design from an old dos/windows "database" program from 10 years ago, with numerous files making up the "database" linked by filename relations.
Anyway, this isn't the point.
The point is, that sitting back, looking at the issues, I can turn Links SQL 2.0 into a thumbnail gallery, picture post, postcards application fairly easily (templates/graphics aside). It requires a few mods to a few routines, database changes, and then an upload/convert set of utilities which seem to be based on ImageMagick as the standard now (that is included in many Unix systems now, and is [fairly] easily installed via CPAN or direct).
Let me explain a few things (those of you around almost 2 years ago might remember some of this from some musings at that time).
1) This is geared as a scalable solution, so that if you have 20 photos, it's exreme overkill, but if you grow to 20,000 the same process should work without change.
2) It does _not_ use flat file, multiple odd, hodgepodge linking. It's all SQL database/table based.
3) For now, (this stuff can change most likely once the program is actually working -- ie: bells and whistles) -- it has to make a few assumptions, based on stock-agency type indexing.
3a) each photo has a UNIQUE name/index number (this does not exclude a download name, title, etc)
3b) thumbnails have the same name as the main file, and are generated and kept in a subdirectory. (I thought about doing .EXT .ext, but that only works for Unix, and creates _major_ problems in the long run.) (I thought about using prefix or post-fix notation, but those have severe problems as well.)
3c) Disk layout does _not_ necessarily have to match the "gallery" layout. What this means, is that images can be kept on-disk in any format you want, by author, by year, etc, while the "directory" can be kept in a human-friendly format by category, or whatever. This is done by a relation such as the CatLinks file (more complex, but go with it for now).
3d) The Database and Images can be re-linked, if necessary, so that if the system got mixed up you can regenerate the directory from the database & vice versa, so that reorganization doesn't destroy the system.
3e) The file-name is the link between the database record and on-disk layout. This means for this "disaster" type system to work, each file must have a unique name matched to the database record. This is not a requirement for the system to work, but only for it to work well ;)
4) As few changes to routines in Links SQL as possible will be made to make it work. Once the plug-ins system is fleshed out completely, it might be able to be turned into that.
5) SUGGESTIONS: if you run this sort of site, or want this sort of site, please let me know now what features you need. Or what sites you like the functionality of.
I'm basing this on 2 years of trying to run the postcards sites, and manage what is really a very large image database. It has _not_ been viewed from the "picture post" or "adult" site angle, so there might be things I haven't thought about in that direction.
Hopefully I'll have a display-only version in a day or so. Maybe that will help with generating ideas.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
But, I came across a program I had looked at before, and this time, was bitten to buy it for a number of reasons. The major one (besides mis-interpreting what it offered) was it seemed to be built on top of a links 2.0 (flat file) shell. Looking at the code, it's not, really. But it's using a design from an old dos/windows "database" program from 10 years ago, with numerous files making up the "database" linked by filename relations.
Anyway, this isn't the point.
The point is, that sitting back, looking at the issues, I can turn Links SQL 2.0 into a thumbnail gallery, picture post, postcards application fairly easily (templates/graphics aside). It requires a few mods to a few routines, database changes, and then an upload/convert set of utilities which seem to be based on ImageMagick as the standard now (that is included in many Unix systems now, and is [fairly] easily installed via CPAN or direct).
Let me explain a few things (those of you around almost 2 years ago might remember some of this from some musings at that time).
1) This is geared as a scalable solution, so that if you have 20 photos, it's exreme overkill, but if you grow to 20,000 the same process should work without change.
2) It does _not_ use flat file, multiple odd, hodgepodge linking. It's all SQL database/table based.
3) For now, (this stuff can change most likely once the program is actually working -- ie: bells and whistles) -- it has to make a few assumptions, based on stock-agency type indexing.
3a) each photo has a UNIQUE name/index number (this does not exclude a download name, title, etc)
3b) thumbnails have the same name as the main file, and are generated and kept in a subdirectory. (I thought about doing .EXT .ext, but that only works for Unix, and creates _major_ problems in the long run.) (I thought about using prefix or post-fix notation, but those have severe problems as well.)
3c) Disk layout does _not_ necessarily have to match the "gallery" layout. What this means, is that images can be kept on-disk in any format you want, by author, by year, etc, while the "directory" can be kept in a human-friendly format by category, or whatever. This is done by a relation such as the CatLinks file (more complex, but go with it for now).
3d) The Database and Images can be re-linked, if necessary, so that if the system got mixed up you can regenerate the directory from the database & vice versa, so that reorganization doesn't destroy the system.
3e) The file-name is the link between the database record and on-disk layout. This means for this "disaster" type system to work, each file must have a unique name matched to the database record. This is not a requirement for the system to work, but only for it to work well ;)
4) As few changes to routines in Links SQL as possible will be made to make it work. Once the plug-ins system is fleshed out completely, it might be able to be turned into that.
5) SUGGESTIONS: if you run this sort of site, or want this sort of site, please let me know now what features you need. Or what sites you like the functionality of.
I'm basing this on 2 years of trying to run the postcards sites, and manage what is really a very large image database. It has _not_ been viewed from the "picture post" or "adult" site angle, so there might be things I haven't thought about in that direction.
Hopefully I'll have a display-only version in a day or so. Maybe that will help with generating ideas.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
Image Gallery/Picture Post