Thanks for the comments, and you raise a good point. I've been meaning to post a debate-thread for this issue, so let's do it here. Anyone else have comments?

I have avoided updating to fb3 for this very reason Donald. I agree with the others, it is an awesome package, but the category issue has been the sticking point for me too.
Thanks from me also for all your great work.

If this is going to be a dealbreaker, it's definitely on the table for discussion.

There are two main reasons I did away with the "pointer file" categories sytem: one, because fb3's categories are not neccessarily included in the main directory and vise versa, and two, because I wanted anyone to be able to copy an entire directory structure to their FTP server without having to worry about categorizing manually.

This leads to some complications that I'd love input on:
1) Given that categories will contain a mix of actual photos and 0-byte pointers, how should files be indexed? If you do not wish your image to appear in the "main" category ($include_cats = 0), what is considered the "actual" file? The first alphabetical category in which it appears? If a user than changes the category, or adds an additional category earlier alphabetically, does the "actual" file then move?
2) (And this is relevant even under the current system:) If a file appears in multiple categories, how should it be sorted? According to the first-created version? The most recent version? The timestamp of the "actual" file?

I'm actuualy a big fan of the new category format, as it's very user-friendly, even for a novice. All a user has to do is make a directory and drop some pictures in it; Folderblog does the rest for you. You don't even need that 'category.txt' file, if you name the directory as you want it to appear in Folderblog. Very nice and simple (and "simple" seems to be the buzzword for Folderblog's approach).

I can't believe that folks are really so hot and bothered about the loss of server space due to a few repeated JPG files. We're not talking about gigabytes, here. Even with something like 10Mb of file space, Folderblog isn't going to make that much of a dent.

Indexing images by the timestamp they have when the file is created on (or uploaded to) the server seems the best approach, as this marries with the idea of this being a blog (the most recent change appears first). Even as a gallery, this seems fine. With EXIF, you can see when the photo was taken, and even without it you can add a note in the caption about when the image was made.

Elwing, a number of us have been folderbloggers benefitting from the zero to low file size of the files in the categories subfolders under FB 2.02.

That fact actually affected into how many categories I 'placed', or labelled in other words, almost all my photographs.

As there was little Megabyte space needed, I simply placed one photo into sometimes 5 or six categories and often at least two categories.

I have 450 + photographs, some at higher quality, hence big file sizes in the 160 KB to 300 KB amounts. I am currently close to 30 MB for all my photos on my server. If I hadda truly duplicate my current category usage under FB 3.0 Beta as is, I estimate my server space needed would balloon to 180 MB.

At this point, what would make me upgrade from FB 2.02? The catchpa spam blocking solution in FB 3.0.

Why haven't I even gotten around to creating a FB 3.0 Beta demo subfolder just to play with fb 3.0? The category multiple folder system as is.

The other funny thing, is that when people on dial up, and yes they do exist and do visit photoblogs, EVERY time they visually see the same photograph but in a different category, will the browser understand to reload the image from local cache, or will it load it up fresh? With fb 2.02, to me, and I might be wrong as I'm on hi speed, one loaded, regardless of category, it instantly appears.

My two cents.

what is current state of the category-name txt-files? are they still needed? if i put spaces in the folder name is it working? (as i read somewhere that spaces in folder-names "can" work, but it is OS depending...)
donald, did you have a look at the zip-file i posted?
what you think about that way?

How about having an extension that implements the old category system from fb2 in fb3, which by default would use the current system? Is that possible? Seems to me that making fb3 work simply as standard, and having something more complex or fruity happen via extensions, would be the best compromise all round.

I'm not using categories for now, but maybe some day, when I have plenty of images, I will. And the behaviour I would expect, is simply make a new folder, copy the images into it and you're done. That is simple, that is logic and so, from my point of view, the way fb3 is doing categories is the right way.

I agree that it is a logical way to do things, but logical does not always equate with efficient or bandwidth friendly. Don't get me wrong, I have just uploaded a test site using folderblog 3 to my server and I am VERY impressed with it's ease of use.
However - I have just started a lomography site & gallery for Australian lomo photographers ~ http://www.ozlomography.com ~ and having a separate category for each individual artist and then for each different kind of camera used is going to start eating into A LOT of storage space, so for now I feel constrained to use version 2. If v 3 had all it has with a txt based solution for categories I would use it in a snap. Once again, I must express admiration at all Donald has been doing here however!

Would you please check this error message pls? Notice: Array to string conversion in /home/paginas/jazzero.com.ar/fotos/index.php on line 493

Mu index.php is the standard packed file. Thanks !!

It's been 10 days since the last exchange here. What's the latest thinking?

I'm very intrigued by folderblog and will look at it tomorrow. I'm a programmer and so might find myself experimenting with a few hacks, provided that you haven't already resolved the problem.

I'm in favor of satisfying both of these requirements:

- Related image files occur in the same folder.
- No single image should have more than one URL.

I'm hoping to physically group image files not by category but by their spatial/temporal relation. I'll have a series of shots documenting some story, and I want to group that story together. My categories are likely to vary from image to image.

So for me it might make more sense to list the categories on a per-image basis, perhaps in the caption file -- or perhaps to pull them as keywords from EXIF. But this puts the onus entirely on the software for indexing images by category.

In this case the software would be free to chose the mechanism for maintaining categories. It could create a tree structure with non-empty pointer-files (each pointing to the target image), or it could keep flat files, such as one per category. You'd have to choose a reasonable refresh policy though, such as a manual refresh or one induced by uploading images.

This sounds like it would be a be of a rework, though. Meantime, you could make the user responsible for naming the location of the actual image within a pointer file, instead of having empty pointer files.

For my purposes, I don't think I could use folderblog if I were forced to organize my image files by category. I need to think of each image as having a unique home where I expect to find it, where I can replace it if need be, where I can update it's caption, and where I keep images that in my mind are so related that I expect to find them together along with no others.

Putting the category list with each image might satisfy the motility requirement you have in mind.

I think you actually implemented albums (hurray!) and categories are still TBD.

Joe, it works like this:
The user uploads whatever files they want into whatever folder structure they want. (So I'll have one folder for people shots, one folder for vacation shots, et cetera. The only requirement is that the root folder must contain at least one image.)

Folderblog assumes any files that have the same filename are the same photo — so requests for vacation/photo12.jpg all redirect to people/photo12.jpg (assuming people/photo12.jpg is the first found occurence of that filename).

Users can then use the /post/ interface to post additional files, or change the files the categories belong to. Any files created by the post interface are 0-byte files that simply indicate the inclusion of photo12.jpg in whichever category.

I know WordPress handles categories by creating a database table, then it assigns ID numbers to the posts and categories and lists them in the database.

Another idea might be to keep the folder structure trick to partition the categories, but instead of 0 files, include a text file with the names of the image files listed for that folder. When an image is updated in the post.php, it's file name is added to the text file of that category.

I personally find creating 0 files kind of annoying, and I don't really like the idea of having redundant files all over my server. Just a thought.

Jason, the /post/ interface creates the 0-byte files for you. I want to avoid using a database, and this seemed the most intuitive compromise: users who don't know anything about folderblog can still quickly create categories by duplicating the folders on their computer, and the rest of us can use the post interface.

Thanks for your input, though — it's always hard to walk the line between the "best" system and the simplest sstem.

I agree that duplication of a full size image seems a bit odd - I thought FB2 had that almost right. There seems no real need to have anything other than a placeholder because in essence that is all it is, just a pointer or flag to express category.

I totally agree with HiMY... since I'm in the same situation. With some 330 pictures so far, most of them around 100 Kbs each, and placed in at least two or three categories each... I just don't have space enough in the server!
Not to mention the issue about people with dial up connections (for example myself!) needing to load several times the same shot.
FB3 seems to be a great piece of code, but i just have to stick with FB2.
However, we all thank you donald for all your work. You have my endless admiration!

elpeaton, folderblog 3 has changed to folderblog 2 compatible categories! It now accepts either full-sized duplicates or 0-byte (fb2-style) pointers.

What I used to do was download ALL my thumbs, created by FB 2.02 on the server, on to my home computer.

I would then re-upload the thumbs into the categories I wished them to belong to.

I did this due to laziness and hassle-factor in creating zero byte files.

Thumbs have tiny file sizes, hence I didn't mind the cumulative increase in total file size across all my categories' subfolders.

In essence, what I was doing with categories in FB 2.02 using thumbnail files, was what you originally had FB 3.0 doing with full size images.

Donald, If I continue this habit after I upgrade to FB v 3.x , Will the thumbnail sized photograph show up for website visitors when then view images by category or will everything be normal and the full size image will be shown on screen when viewing photos via categories?

Sorry for the hassle factor in answering this question.

:-)

Since it appears that categories are used by some but not all, why not remove categories from the core FB and make it as an extension? This would allow other people to develop their own implementations as they see fit and share them with the world. That way, FB3 remains tiny, and people are free to use whichever Category system plugin/extension they prefer?

P.S.
Donald, this would also allow you to focus on the core structure to improve little things here and there - without the added complexity of a category system getting in the way.

P.P.S.
I haven't looked at your extension API yet.

Everything will be normal. Folderblog 3 categories are basically Folderblog 2.02 categories with one difference: no need to put the "master" copy of the image in the photos/ directory.

Why bother doing all that work with thumbnails? Since folderblog 2.0 you've been able to create the 0-byte files directly via the post interface.

Donald,

for the life of me, auto zero byte file creation for categories via the post interface... it never worked for me. (My install actually deleted existing category pointer files, and not create them. No matter...)

I bothered with it over a number of days, fresh install, chmod'ing permissions adfinitum, etc, until I got comfortable with the upload thumbs into categories sub folder habit.

Donald, I appreciate your entire effort and value and do recommend folderblog as an engine for photoblogging to anyone who asks.

It's all good dude.

What a kiss-ass. ;)

hahahahahahahaaaa

Well, that's a scalable and very flexible solution what you've created Donald. Thank you very much. That's exactly what I need for one of my new sites wich is about models.

Forgot to say that for my Models site I rather strip out the comments feature from your script. It's not needed for me anyway. Thanks again.