Blogging Roller

As I have said before: here's to the complainers. Those who care enough to complain are an important asset to any software product. Hani is the king of whiny-ass complainers, of course. He can't do anything except complain, that is the charter of his blog after all and he is locked into his own stinky little cage, but I do still appreciate the constructive criticism that he makes in his recent weblog entry about Roller. Here are the improvements that he suggested, minus the childish and poorly written bile:

• Editor UI: add a dismiss button to the popup calendar
• Editor UI: document plugins in Roller user guide
• Editor UI: provide comment count
• Editor UI: the allow comments on entry flag should default to true (fixed)
• Weblog search: add paging for lengthy search results
• Weblog search: problem with search results?
• Main page: Font sizes too large on main page (fixed)
• Main page: List weblog name rather than user name in hot blogs list (fixed)
• Main page: Provide option to view main page with out excerpts
• Edit user page: default locale to en and timezone to America/New_York (fixed)

We will be deploying new Roller 0.9.9 builds to JRoller over the next couple of weeks and we may have the opportunity to make some of these improvements, but these are not the only problems we are tracking and the all-volunteer Roller development team has limited time to commit to Roller. If you really want to make Roller better, it's up to you. Roller is open source software and you can help to make it better by filing bug reports and suggestions to Roller's JIRA issue tracker, by submitting patches, and by helping out with documentation on the Roller Wiki.

Roller is the most popular and successful weblogging software among Java bloggers, was recently chosen by Sun to power blogs.sun.com, and is enjoyed by thousands of webloggers worldwide. Join us, help to ensure Roller's continued success, and make a difference in the open source Java community.

Wiki syntax seems to be working just fine in Roller 0.9.9 as demonstrated by this fine quality Wiki-Blog post.

I'm not sure why your _entry page template is not working, Matt. Perhaps one of the macros you are using has a different call signature than it did in 0.9.8?

The good news is that, with Lance's improvements to the plugin pipeline, you no longer need that _entry page template to enable Wiki syntax. If you have the Wiki plugin listed in your web.xml and you have the Wiki Syntax checkbox checked on your Website:Settings page then you will see a Wiki Syntax checkbox in the Weblog Edit page. You can enable Wiki Syntax on a per Weblog entry basis by setting that checkbox.

By the way, Wiki support is not enabled on JRoller.com because there is no Wiki on JRoller.com.

I have successfully upgraded JRoller.com to Roller 0.9.9. If you encounter any problems please report a issue on Roller's JIRA issue tracker located here: http://opensource.atlassian.com/projects/roller.

• For all users: Roller now supports locale and timezone settings for each user. You can set your locale and timezone on the Website->User page of the Editor UI.
  
  
• For users (excluding Hani) who have customized page templates: if you added a call to $pageModel.getRecentWeblogEntries() in your weblog templates, you will need to add a second argument to the call. In Roller 0.9.8 the method took only one argument, an integer being the number of entries to return. In Roller 0.9.9, the method takes a second parameter, a string being the category of posts to be displayed. Pass in "/" to include all categories. For example: $pageModel.getRecentWeblogEntries(15,"/") would get up to 15 recent entries in all categories.

I worked out the problems with the database upgrade scripts and code. I'll be upgrading JRoller in the next hour or two.

UPDATE: upgrade is underway.

I've got a table that looks like this:

create table comment (
    id         varchar(48) not null primary key,
    entryid    varchar(48) not null,
    name       varchar(255) null,
    email      varchar(255) null,
    url        varchar(255) null,
    content    text null,
    posttime   timestamp not null,
    spam       bit default 0 not null,
    remotehost varchar(128) null
);

And I want to set the spam field in all rows to false like so:

update comment set spam=false;

But that command also resets all of the posttime fields in the table to the current time. If I use the following command, my posttime fields are preserved.

update comment set spam=false, posttime=posttime;

What's up with that? Why does an update of one field affect other fields?

I think Roller 0.9.9 is ready for prime-time and I plan on deploying it to JRoller this weekend. I spent the last couple of nights testing the upgrade process using a very recent copy of the JRoller database and I believe that I will have all of the glitches worked out by this evening. I will post an announcement here a couple of hours before I begin the upgrade, which I hope will take less than an hour.

The plan is to upgrade JRoller to 0.9.9, get feedback and bug reports, fix bugs, release 0.9.9.1, get feedback and bug reports, fix bugs, release Roller 0.9.9.2, and then repeat the process until we are ready to declare victory. Once we reach that point, we'll call it Roller 1.0 and release it on SourceForge.

The major new features of Roller 1.0 will be a new Editor UI, hierarchical categories, hierarchical bookmark/blogroll folders with OPML import/export, Atom API support, Atom newsfeed support, a new look-and-feel in the Web interface, lots of other features, and numerous bug fixes. Some of these features may be disabled in the Roller 0.9.9 cut that I will deploy this weekend.

Eric Sink: Microsoft's new enterprise-class source control tool was written from scratch by a team in the Raleigh-Durham area. The team is being led by Brian Harry, the guy who originally developed SourceSafe at OneTree before it was acquired by Microsoft.

So much for Vault. Seems to me, Eric made an error in choosing his competition.

I followed the PostgreSQL installation instructions on Apple's site and got PostgreSQL up and running in no time. To make PostgreSQL start when MacOS starts, I had to do a little more work. I added a startup item as described in James Duncan Davidson's Running Mac OS X Panther. First, I created a startup item directory and used vi to create a parameters file:

root# mkdir -p /Library/StartupItems/PostgreSQL
root# cd /Library/StartupItems/PostgresSQL
root# vi StartupParameters.plist

Next, I guessed that PostgreSQL requires Directory Services and uses Disks and came up with this StartupParameters.plist file:

{
   Description = "PostgreSQL Server";
   Provides = ("PostgreSQL");
   Requires = ("DirectoryServices");
   Uses = ("Disks");
   OrderPreference = "None";
}

Finally, I wrote a startup script to start, restart, and stop PostgreSQL:

#!/bin/sh
. /etc/rc.common
StartService() {
   echo "Starting PostgreSQL"
   sudo -u postgres /usr/local/pgsql/bin/postmaster -i -D /var/postgres/rollerdb &
}
RestartService() {
   echo "Restarting PostgreSQL"
   sudo -u postgres /usr/local/pgsql/bin/pg_ctl -D /var/postgres/rollerdb stop
   sudo -u postgres /usr/local/pgsql/bin/postmaster -i -D /var/postgres/rollerdb &
}
StopService() {
   echo "Stopping PostgreSQL"
   sudo -u postgres /usr/local/pgsql/bin/pg_ctl -D /var/postgres/rollerdb stop
}
RunService "$1"

Once I was done with that I tested starting, restarting, and stopping PostgreSQL using the SystemStarter command. Once the script worked, I rebooted and found that PostgreSQL did indeed start on startup. It works, but I wonder, is this the best way to configure service for Mac OS X? Davidson's book menioned xinetd and mach bootstrap servers, but says that the SystemStarter is the way to go for now.

VeloEclipse is a fork of the, apparently inactive, VeloEdit project that has been updated to work in Eclipse 3.0 M8 and later.

A number of folks have been taking a closer look at Roller and making note of the various problems and shortcomings that they encounter. Henri Yandell put together a list of Roller Grumbles, Michael Koziarski posted some notes on evaluating Roller, and, as a result of new feature discussions on the Roller-Dev mailing list there is now a Roller Wish List on the Roller Wiki. Drop by the mailing-list or the Wiki and make your voice heard.

Henri Yandell has written a Movable Type to Roller migration script.

New JRoller blogger Vlad Hanciuta posts some first impressions of Eclipse 3.0 M9.

After reading Matt's post, I was a little concerned about Powerbook performance. I'm not concerned anymore. On my Powerbook (1.5GHz, 1.25GB RAM) a full Roller build takes 53 seconds. On my Windows XP desktop box (2.4GHz, 1GB RAM), a full Roller build takes 45 seconds. I don't even notice the difference.

I have to retract the bad things that I said about Eclipse and Fire. I've been using Eclipse 3.0 M8 on MacOS for a couple of weeks now and, while it is not pretty or as snappy as the Windows version, it is definitely usable. Kudos to the Eclipse and SWT developers. I stuck with Fire and it has really grown on me. I use it for IRC, AIM, and YahooIM and I enjoy it as much as I do Trillian on Windows. I'd like to see more IRC features, but that's my only complaint.

Nerd news site Slashdot caught wind of the JBoss Group's slimey business tactics, linked to three weblogs on JRoller, and proved that Roller can survive the Slashdot effect. This says a lot about Roller and the technology stack that supports Roller including Tomcat, Struts, Velocity, Hibernate, and especially OSCache. Via Rick Ross.

Lance Lavandowska: Roller needs more "community" to get where it is going.

In case you missed it, Don Brown took my Control Flow meets JSP proof-of-concept and kicked it up a notch. He implemented Struts Flow and made it part of the Struts Applications project on SourceForge.

Turn off the LAMP and crack open an ice cold PBR - Pebble, Blojsom, or Roller that is. You're a Java developer so drink your own brew. If you don't like the taste, then join one of those open source Java weblogging projects and start brewin' for yourself.

I've been doing a little informal research into Wiki software options and Wiki APIs. I'm trying to understand the state of the Wiki software market, if you can call it that, and especially the state of Wiki APIs. This post is a summary of what I have learned so far.

Where we are

The WikiRpcInterface is supported by the most popular open source Wikis including UseModWiki, MoinMoin, PhpWiki, Twiki, and JSPWiki. Using this XML-RPC based API, you can:

• Get a list of recent changes in the Wiki
• Get Wiki pages in raw Wiki syntax format or transformed into HTML
• Get Wiki page metadata including name, last modified time, author, and revision number
• Get a list of all links on a Wiki page
• Create and update Wiki pages

Where we could be

Unfortunately, the list of Wikis that don't support the WikiRpcInterface is a lot longer than the list of those that do. For example, the popular open-source Java-based SnipSnap Wikiblog doesn't support it and neither does the Atlassian's new closed-source Java-based Wiki Confluence. SnipSnap provides no Wiki API at all. Confluence, on the other hand, supports an extensive API in both XML-RPC and SOAP-RPC flavors. With the Confluence API you can:

• Authenticate (login and logout)
• Manage Wiki user groups and permissions
• Get Wiki "space" and the Wiki pages within it
• Get Wiki pages in raw Wiki syntax format or transformed into HTML
• Get Wiki page meta data including previous revisions of the page
• Get a list of all links on a Wiki page
• Get comments and attachments associated with a Wiki space
• Transform Wiki syntax to HTML
• Search the Wiki

That's a pretty impressive list of capabilties and it has already inspired a slick GUI client called TimTam. Take a look at the cool screenshots. It's really a pity that TimTam only works with one Wiki - and a payware one at that.

A side note: I wanted to find out more about Wiki API support in the closed-source Socialtext Wiki/Weblog product line, but the Socialtext website is not very sociable. I could not find any detailed product information, documentation, or developer information on the site. They don't even have site search. I'm not ready to register for a free demo or marketing spam yet, so I'll look into Socialtext at a later time.

The way forward?

Recently, Joe Gregorio published an article called An Atom Powered Wiki. Joe showed how to add Atom API support to a simple Wiki. Joe's example API is very simple, only allowing getting, putting, and deleting Wiki pages but, because Atom is exensible, and in a SOAP compatible way, the Atom API could easily serve as the basis for a new standard Wiki API.