I didn't like that the display for <#Recent> threads vs. [#Unread] threads on the discussion areas box was inconsistent (in that, when you're logged in, there may have been no third column displayed if you didn't have unread items). In the case where you're logged in and you've read everything, the Discussion Areas display will "fall back" to displaying the <#Recent> posts rather than omitting the column entirely.

Also, I added a few extra search links on the Discussion Areas box. Basically, when you see a number you can click on it, and see which posts correspond to the number represented as a result of a search. When logged in, you can click to search on your unread posts. When logged in or logged out, you can click on the post counts in either the (#Comments) or <#Recent> columns to see which posts correspond to that item, or which posts in that item correspond to the last 50 or so posts.

SPDCA: The other direction.

I convinced myself that idkfa needed to have an "unread" feature. That is to say: after I spend incredible amounts of time getting the "read" part right, I felt I might find value in going the opposite direction. So now, instead of a "speedreading" feature, we also have a "un-reading" feature for marking certain posts as unread.

Like the speedreader, it's plugged into the search feature. Basically: search to find a data set you're happy with, whether it be an item, a thread (one of the icon links, if you're interested), a single post, etc., you can choose to mark it as read (speedreading) or unread (un-reading).

This helps me in a few ways:

1. When I want to test this feature, I can now un-read without having to go into the database.
2. If you want to save something for later, you can mark it as unread.
3. If you did a "speedread," but mistakenly marked something as read when you didn't want to, you can undo your mistake.

I realize this probably isn't an absolutely necessary feature. But it makes the seen/unseen mechanism more complete, and gives you control over it to make it conform to the way you want to read a post.

Also, I was a bit bored, and looking at forum features on other sites / softwares. I liked the idea of abbreviating post counts by listing them in their appropriate kilo- (K), mega- (M), or giga- (G) notation. It's unlikely we'll ever see 1,000,000 posts, or even 1,000,000,000, but it saves a little bit of space.

SPDCA: Cookies. For the longest time I've fought with browser cookies.

(Browser cookies are small, named variables passed between a web server and a web browser. They are what allow servers to maintain stateful information about you (Are you logged in? What is in your shopping cart? etc.) over the course of your browsing session. They often looked upon as the least sophisticated part of the HTTP protocol specification.)

In all of my previous projects, I have simply tried to get the cookies "right," and then walk away and never touch it again. In v2, they were a goddamn mess. Not only was I passing back and forth your username (something that's easy to guess and/or forge), I was also passing back and forth your plaintext, unencrypted password (something that is notoriously easy to spot if you were, say, listening in on a coffee shop wireless, etc.). Even worse: upon every page access I tried to "update" the cookie so its expiration time would be pushed further out. Each time I did so, I told the server to re-send your password in order to update the timestamp. It's probably for the best that I shut that baby down.

For v3, I decided I would try to address the problem. PHP (the programming language I designed idkfa in) has built-in session tracking functionality that takes care of things like encryption, session creation / breakdown, complex data types stored within the session, and session validation.

Unfortunately that decision, up until now, has caused my idkfa logins to last around 24 minutes unless you were a) a user actively accessing the site, or b) sitting on auto-update.

This is for the following reasons:

• The session_set_cookie_params and session_cache_expire functions both take time values to determine how long a cookie should be issued for, and how long that cookie should be in the system's cache. The former takes its time value in seconds. The second takes its time value in minutes. The documentation reflects this poorly.
• The session_start function does not update the timestamp on a cookie (that is, doesn't tell your browser to move its expiration window further upon page access). It just builds the session in memory (if the session exists), but nothing else. I had assumed otherwise, and without discovering session_set_cookie_param, I wasn't setting any timestamp at all (leaving it up to the web browser to clear the cookie entirely when it shut down).
• There's a chicken-and-the-egg problem when it comes to maintaining "who is online?" records in a database. You can tell a page to start a session, but you can't reliably ask if the session's cookie was "set" until a page-load later. So how do you say "this is when somebody logged in?" Well... I haven't quite figured that out yet. As of now, I still make a few bad assumptions, but it works out in 90% of the cases. Where it breaks down is if a web client (say, a search engine accessing the page) doesn't accept a cookie. Because my script is always trying to set a cookie, and then maintain its "online" status, I end up generating hundreds of "online" records for a single user. (Somebody was doing this last night, which is why I was looking at this in the first place).
• Finally, even though I figured out the cookie expiration stuff, I was still having problems keeping my sessions from expiring. Turns out, it has a lot to do with how idkfa is hosted. By default, my hosting service stores all of its session data in a single directory. PHP, to save time, only "expires" session data after a random period (usually shortly after when the time the session was to expire at the time of session creation), where if the "dice" are rolled a certain way, PHP performs its "garbage collection" routine, and removes old session data. The problem with this, though, is PHP doesn't care about which user, or which website, or really about anything when it comes to kicking off its garbage collection. Here's the kicker: if any PHP instance thinks it needs to garbage collect, it can destroy any cookies in its session storage directory. This means that even if I was setting my session lifetimes far, far into the future, anybody who set theirs to the defaults (~24 minutes) had the potential to destroy my sessions along with theirs.

When I woke up this morning I was surprised to see myself still logged in to idkfa. It's been a while. But I think I've got it "correct" now, but I'm still watching it.

Added blockquotes to the list of available formatting/tag options in idkfa posts. For example:

...you can now quote things (and have things be formatted without the quotes) and have them appear indented. This is a good way to distinguish your own text from lengthy, quoted text.

Fixed up some of the styling on the search page. SPDCA.

(www.reddit.com)

Another "nice to have" thing I've wanted for a while: for plain links that are excessively long, I am "collapsing" them so that they don't mess with the formatting of the comment boxes. You can still explicitly link things of arbitrary length (making normal text appear as a link (php.net)), but using a lengthy URL (https://picasaweb.google.com/lh/photo/ywObKSO0AlKzBeedzVyADi2TBFbFtxRPtqpluxrkO2Q?feat=directlink (picasaweb.google.com)) will attempt to collapse things, like so:

https://picasaweb....O2Q?feat=directlink (picasaweb.google.com)

So the question is: why am I collapsing in certain places, and not others? Well, it depends on your browser. Some of them (apparently Chrome, and IE) automatically wrap links pasted into special "textareas" like the comment box with the correct linking tags. I might try to address this in the future to collapse explicit linking as well, but we'll see.

Random thought/idea: So say I see that there's 3 new posts that I haven't read in Mercy General. I click on one of them and they all happen to be in the same thread, but since I clicked on one of them, they're all counted as read. The big thing here though is how do I distinguish which ones I haven't read yet on the thread screen? Can the windows be outlined or something to show that they're new? Maybe I'm missing it, but that would be nice. Then if I hit F5, since they're already read, the outline goes away.

So if I theoretically wanted to upload an audio clip to idkfa, would I have to just make a link to another site? Like upload it on my website and link to it there? Or is there a way to embed it in a post?

Theoretically, I've upgraded the post box to include the latest revision of the CKEditor Javascript library. Part of its new fixes/featureset is that it includes support for iOS5 devices. I have no such devices immediately available, so you'll have to tell me if there's been any improvements made, but I have high hopes.

JOSH.

It might be cool to be able to post to the thread originator post without having to click on it first. Thanks.

It would appear that if you had a password longer than 15 characters, resetting your password on idkfa would have been somewhat impossible.

Should be fixed for passwords up to 30 characters now.

Last comment I posted had all kinds of weirdness associated with it.

Happy Birthday, idkfa v3.

I hope you've enjoyed your last year of waking un-life.

On the settings page, I have a small section that lets you see how many edits you've performed this month. You're welcome.

On the "Preview" page, I've now got it where it shows the post you're replying to in addition to the preview of the post you're currently working on. Not perfect, but better than being forced to open a number of tabs.

Doing some modifications to idkfa. It occurred to me, late one night, that the new caching mechanism, which has been saving you from precious hundreds of milliseconds of load time, was operating sort of dangerously.

Dangerously, in that if two or more people clicked on idkfa at the exact same time, and accessed the same content (very likely to happen), and kicked off the same cache updates, then it was possible that those two updates could conflict with each other, or even overwrite or corrupt the other. I haven't witnessed this happening, and there are "handlers" for cache errors already in place, but I'd like to avoid the situation altogether.

So now I've added a locking mechanism to try to avoid such things happening. You can now operate idkfa safely knowing that your keypresses or mouse clicks are theoretically guaranteed to not destroy cache entries.

There's now a "View Saved Drafts" feature, which lets you view which drafts you have saved to idkfa (and were not cleared upon posting). It's a good idea to check this on occasion, see if maybe you forgot to write something, or if my system carelessly saved something you didn't intend to have saved.

You can access it from the "my idkfa" drop down.

Uh, yeah. idkfa's hosts have been having a hell of a time keeping its filesystems running out of... files. Don't expect much from idkfa until they get it resolved.

Well, if everyone else at work takes 2 hour lunches to play cribbage, I'm entitled to work on idkfa during my lunch hour... and a half.

Implemented a caching system, sort of similar to what we had on idkfa v2, but with improvements due to some hard lessons learned previously.

• On v2, I was caching HTML output, such that whenever you generated something like the "Discussion Item" widget, it saved the structural HTML code for that, and would return that based on a cached file. However, any time I needed to make changed to that HTML code, I would have to find a way to manually clear the cache. This meant that for every change I made, I either had to wait 5 minutes for the cache to clear, or would have to delete a file manually. By the time I was finished with v2, this was a maddening process.
• Saving the HTML output of a function meant that I never had to spend time processing data again, I could just spit a file back to the user and be done with it. This, however, meant that based on whatever I could be processing, I could be caching a ton of data in order to save the full output. For idkfa v2, that meant all of my super-inefficient HTML was being cached, and sent back and forth, no matter the size of the data set that the output had been generated from.
• Every function I wrote that I wanted cached I had to do on a case-by-case basis. This means I would have to copy code from one function to another each time I identified a place that could benefit from caching. Not only did this increase the length of the code written, but made it severely complex for which portions should/should not have been cached, and parameters for how to cache it (where to cache, how long to cache, etc.)

Now I'm caching data sets. That is, rather than caching HTML output, I'm caching the data structures returned from the database. And I have two standardized functions to do so (encache, and decache), that support all of the parameters for caching, and those two functions can be used to cache anything (queries, HTML output, whatever I want, really). In addition, because I'm caching queries instead of HTML, I can make improvements using caching without having to worry about whether I'm being called from a normal page load or an AJAX page load (the auto-updating stuff). And being that I can apply caching to anything, and with some ease, I'm hoping to speed things up here in the future for idkfa users.

So far, at least for my kaiden user account, I've taken page loads from 300+ milliseconds down to 70 milliseconds. This is possible because I've been able to make things like generating the Discussion Item widget and Latest Posts widget take near to zero time to process, leaving time instead for more dynamic things like the seen/unseen queries, or the users online queries.

Thinking on some potential UI changes for displaying threads.

Currently, we view 1 post at a time, with slight indications elsewhere in the thread as to where the message is that you're viewing. I have it this way for a few reasons:

• Each post can be read without distraction from other posts.
• Upon accessing each post, it is unmistakable which post you are reading.
• You aren't presented with a wall of text upon clicking on something.
• There is always one location on the page to read a post, not several, and you'll never have to scroll to read what you're going after.

I'm proposing to find a way to display all posts, in their entirety (or at least, in their entirety without having to navigate to a different page), for the entire thread.

This is because in trying to reply to a number of posts recently, I've wanted to review something in a previous post in the thread, but I didn't want to navigate away from the page I was currently on.

Other threaded comment systems (see: Reddit) do something similar, but then sort by popularity, which is often pretty irritating if you're trying to read the progression of a discussion.

Anybody have any thoughts on this? Like the system the way it is? Wish it was different? Care at all?

Fiddling around with the idea of an icon to represent "Unread Messages In Reply to You." If you log in, I've currently got one working next to where it says "Welcome, [user name]."

(I think, I don't know, nobody's actually replied to me yet).

Currently, it shows the "search" icon if there are no messages, and the "reply" icon if there are unread posts in reply to one of your own posts. Clicking on the icon in either case brings you to the search screen which shows you the full results of the "Unread Messages In Reply to You" query.

Governator, does your Jabba the Hutt snowman exist in real life? In Anchorage?

Playing around with something else I was thinking about last night. My usual method of using idkfa was to have one tab be auto-updating, and the others I'm browsing/typing in just be "normal." That seemed more complicated that necessary.

Now, when you're navigating from page to page, whether you're in auto-update mode will stick with you, and persist until you click it off with either the key combo or the update icon.