Thanks to everyone who has expressed in an interest in seeing this release happen. It's been encouraging. Hopefully I'll find a weekend soon where I actually have time to roll it out. Now, If you'll excuse me, I have bigger fish to fry.

Happy Holidays everyone!

My last post demonstrated some of the major changes to expect in syntax between now and the second release candidate of NanoBlogger 3.4. In many cases these transformations might appear similar to the behavior exhibited in versions 3.3 and before. In other cases they will be radically different, but in any case, I'm confident that most people will view these changes as a welcome improvement over 3.4 RC1.

Just to reiterate, the following changes, while primarily focused on changes from the previous release, are still relevant when compared to earlier versions.

List of Syntax Enhancements & Changes:

synopsis: nb [options] <action> [keyword (variable)]

add action:

The add action has been reworked to accept one of multiple keywords. Keywords include: article, entry, tag and weblog.

example 1: nb add entry
example 2: nb add tag

list action:

The list action, while not much different than 3.3's "--list" option, has been enhanced to accept a second argument as input for a tag's ID number. Eliminating the need to use the "--tag" option to list entries by tag.

example 1: nb list tags
example 2: nb list main
example 3: nb list tag 3

edit action:

The edit action has been enhanced to accept one of multiple keywords. Keywords, "tag" and "entry", should be followed by an ID number. Where the keyword "file" expects a filename. The edit action in 3.4 RC 1 had no keywords.

example 1: nb edit entry 5
example 2: nb --title example2 edit tag 2
example 3: nb edit file somefile.txt

delete action:

The delete action has been enhanced much the same way the edit action has been. The only difference is that it's intentionally missing the keyword, "file". The delete action in 3.4 RC 1 had no keywords.

example 1: nb delete entry 5
example 2: nb delete tag 2

update action:

The update action, while no different than 3.3's "--update" option, no longer requires the "query" action for manipulation like it did in 3.4 RC1.

example: nb update main

import action:

The import action replaces the so called, "file" action and accepts one of multiple keywords followed by a preexisting file. Keywords include: article and entry.

example: nb import entry somefile.txt

Additional notes:

• The previous actions, formerly known as "query" and "tag" have been regulated to their equivalent long options, "--query" and "--tag". The "--tag" long option must be used when you need to manipulate entries belonging to a specific tag. The "--query" long option is useful for narrowing the scope of entries to be managed.

• Every action has always included a default query, In 3.3 this was changed to return a limited amount of results. As pointed out on the mailing list, this could be point of confusion, so it has been changed back to pre-3.3 behavior of not defaulting to a limited query. The default query can be changed through the configuration or overridden from the command line.

• Short options are also provided for many of the actions and long options.

Somewhere in the transition from a dash-based only command line interface to a more flexible action-based one, some clarity has been lost. Having narrowed it down to the "add", "edit" and "delete" commands, I found the obvious solution was to clarify the subject of the action. Basically, employing strong visual cues which help provide the necessary distinction.

I think the results speak for themselves:

Now instead of:

nb edit n

or more confusing vagaries such as:

nb tag n delete n

We have nicely clarified commands, such as:

nb edit entry n

nice separation between what's a tag and what's an entry:

nb tag n delete entry n

in some cases we see an elimination of redundancy:

nb delete tag n

where before it was:

nb tag n delete tag

and in other cases we see an elimination of complexity:

nb --title example add tag

where before it was:

nb --title example add tag new

For the translators this will only require minor changes to the syntax of the effected commands.

I'd like to get the final release out before September or sooner, but also believe such a change warrants a second release candidate, so expect a second one soon.

As is often the case, once I start focusing on fixing one bug or one feature it often leads to several other seemingly unrelated changes. For example, I'll notice some neglected code or documentation and feel compelled to tweak and tinker even more. And that's indeed what has happened since. So, translators will especially want to take advantage of this code freeze to synchronize their translations with the changes I made up until this freeze. I should note, if it wasn't for the advice of one Denis Bernard, I probably would've been satisfied with just making a release candidate or two. Also, I should note that, the Spanish translation is still in dire need of an update.

Usted hablo Espanol?

We'll see how 3.4 RC-1 goes to determine whether the need exists for another future release candidate before making the final release. And if all goes well, hopefully NanoBlogger 3.4 RC-1 will be released around mid-June.

I finally made the switch to Subversion. With instructions provided by SF.net, I exported my CVS repository and converted it to an SVN dump suitable for import. Since I saw no errors and was careful to remove CVSROOT, I made the error in assuming that the import would go without a hitch. After about a few days of waiting on tech support they gave me the information I needed to hear. The problem was on my end. Of course that "problem" was with all my CVS tags. Not surprising, seeing how they mention that as one of the most common problems that arises when switching from CVS to Subversion. So, I took the road most traveled and left those tags behind.

All of this time spent around my code, lead me to tinkering, which lead to some changes. It's still fun to work on, even if I really should be working on more important things. So, if you're feeling frisky check out the new code! I'm running a Subversion shop now, baby!

If and when I have time, I will be working on rewriting CSS, redesigning the layout, and dealing with bug reports. Seeing how these tasks are currently low priority for me, I was thinking now might be a good time for anyone that wants to join the project to get involved and keep it moving forward. Just drop me a line if you're interested and I'll be happy to set you up.

Best Regards!

update: I even found an article from the developer of vii that shares my sentiment about NB.

update: vii has been renamed to vee.

The solution: The databases must be easily maintained and be able to grow without negative impact to overall performance. So, update_db, update_maindb, delete_db, resort_db, and resort_catdb were created as new library functions that provide a unified approach to managing flat-file databases. The last two are probably the most involved, running the sort command on the database, but still far more efficient than globbing through a for loop.

So far, I'm satisfied with the results and the obvious gain in speed. Although, I imagine anything would beat having to regenerate a database of a thousand entries or more everytime you want to change a weblog entry. I also had the joy of discovering some strange logic behind the build_weblog, paginate and delete functions.

1. slow database acquisition (especially for categories)
2. slow acquirement of related categories for each entry
3. poor correlation of data loaded for category archives and entry templates

The following solutions were conjured up as a result:

1. created master database reference file which also stores related categories for each entry
2. configurable data loaded for category archives allows for better correlation with entry templates

Because of these changes, category archives can now be configured to acquire a minimal set of entry metadata reducing a significant amount of time wasted. Total time to process a full update of my weblog with a total of 87 entries and two categories was reduced by about three minutes!

With some help, I've managed to get the templates converted to XHTML 1.1. Serving XHTML 1.1 involves some work with the server configuration. For apache I've added "AddType application/xhtml+xml .html" to my .htaccess file. In the process, I've added a new variable, BLOG_MIMETYPE, to set the content meta data in the header of the templates. A special thanks goes out to amake for contributing the necessary changes to the default templates.

In the process of this migration I've managed to encounter many bugs. However I don't believe these bugs are from the previous version, but were rather created during my experimentation's. To name a few, I fixed a bug in the moods plugin that would skip every other smiley on a single line. Another potential bug was discovered in the tidy plugin, where files wouldn't be modified if the -m option wasn't set in TIDY_ARGS.

After discovering that tidy wasn't working at all, because I've changed my own TIDY_ARGS to exclude the modify input option, I was a little frustrated. So, I spent some time improving the tidy plugin and I feel I've greatly enhanced the tidy plugin by adding a function to report tidy's exit code and adding a log file, so that errors can be easily reviewed and corrected. Can you tell I've been grokking tidy's documentation lately?