Blogging engines revisited (again)

Well, I’m officially Not Happy with blosxom anymore. The biggest problem is
that the posting process when using static mode becomes very
convoluted. At least for me:

  1. ssh in to the server
  2. Write the entry as a text file (and think of a filename that would
    look good in the URL
  3. Add HTML as neccessary, without any real way of checking if I got
    every tag right
  4. Change all non-ascii characters such as å,ä and ö
    to their HTML entity counterparts (å,
    ä and ö) to get around the issue of
    storing files in Latin-1 and the RSS output being in UTF-8.
  5. Generate static pages by running blosxom from the command line. As
    I use a list of archive links, I need to regenerate each and every
    page to get the numbers right, which takes a while when having 100+
    entries and running stuff on a 166 Mhz Pentium.

Clearly, this is too much work for quick postings, and so I tend
only to write when I have something longer to say. But there are other
aspects of blosxom that I’m not so fond of either:

  • The reliance on filesystem timestamps. I just know that I’m
    someday going to copy all the blog posting files from one filesystem
    to another, and forget to use the -p
    option, thus removing this valuable metadata
  • The lack of any (mature) blog posting API implementation. I’d love
    to use a tool like w.bloggar or any
    of the blogging
    extensions
    available for Mozilla, but neither of the two
    implementations available at the
    plugin registry
    look very mature to me.
  • In general, the extreme spartanity (spartanness?) of the base
    blosxom install. I know this is the zen of blosxom, but I’d really
    like to have basic stuff like:

    • a posting API
    • comments/trackback/pingback recieving
    • a posting webform with trackback/pingback sending
    • a blogroll
    • archive links
    • and a search function

    built into the base install.

So, what am I looking for? The thing that drove me to bloxom was
that it did not rely on MySQL or any other ”big” RDBMS for data
storage. Using a RDBMS for anything less than 10000 items is overkill, and I just really don’t
want to have to worry about having to keep both apache and a RDBMS
running on my tiny little box

But I no longer think that using static pages are the way to
go. Having to regenerate 300+ files takes too long time(blosxom
generates a .rss and .atom file for every blog posting, which
works nice with it’s ”flavor” concept, but not with anything
else).

The data I have to deal with is so ridicously small (right now,
less than half a megabyte) that it would make sense to just load all
the blog postings into memory at startup and just keep them
there. However, this requires a execution model where the program
doesn’t exit after the page is loaded, a la classic CGI
scripts
. Particularly on my really slow box.

So, I think I’m looking for something that uses flat files or an
embedded database like SQLite or
Berkely DB, together with a
continously-running process model like PHP or mod_perl. I’d also love for it to
have a good security record (which I guess rules out most PHP
solutions…), and a easier way of posting images than manually
scp’ing them to my image/ directory.

I’ve been looking at the Blog software
breakdown
chart, but I can’t find anything that matches all of my
requirements/wishes. Pontus is using COREBlog (not listed in the above breakdown), which is built upon Zope. It looks good, supports
Blogger/MetaWeblog APIs (as well as plain ol’ email), and has much of
the other basic stuff that I want. I guess it uses Zope’s embedded
database, which is good enough for me. Maybe I’ll try that next.

The other solution would be to just use a blog host and forget
about running a blog at home. This solution is looking more attractive
by the day, but I can’t really let go of the control that is hosting
things myself.

2 reaktioner till “Blogging engines revisited (again)”

  1. While I certainly have come to enjoy CoreBlog and the Zope environment, it’s rather the opposite of what you’re working with now. It’s also to a large extent what I normally don’t like – I’m quite clueless about most of Zopes internal and can basically only work through the web interface (not that I’ve had need to work with it in other ways, I’m hoping my Python skills will be enough if I ever need to resolve problems that occur within Zope).

    While it has the blogger API, I’ve only just tested to see that it works. I write my posts in Emacs (using the mozex extension for my Mozilla), and it’s convenient enough for me.

    I’m not saying it’s bad for you – I certainly think it’s better if you go with Zope than something like Movable type or WordPress or the like, but you might need to learn to let go of things. I don’t recall why you let go of dasBlog, but perhaps running it upon Mono might be an alternative.

    The problem with blog hosts is (as you point out) that you let go of control – as long as you have basic functionality (rss/atom feeds and users can post comments and trackbacks, ability to change the look and feel), I think I would be satisfied, but problems arise whenever you want something more, and at that time, it might be difficult to migrate to other sites providing that functionality. Except for that, it’s shiny, I think.

  2. Or to make an example out of this, it bothers me a little that the main page doesn’t show whatever there are any comments (basically, I’d like to see the number of comments, so I know if there’s anything new for me to read). As things are now, if you agreed enough, you could fix it (for certain values of could). With a blog host, you’d had to rely on them to fix it.

Kommentarer kan inte lämnas på detta inlägg.