Monthly Archives: February 2003

‘Conneg’ and the duality of weblogs.

Q: When is a blog not a blog?

A: When it’s an RSS feed.

I’ve pondered the relationship between weblog and RSS before, and in an Old Speckled Hen-induced philosophical state of mind, have decided for experimental purposes that for all URI intents and purposes they are one and the same.

With that in mind, my thoughts turned (naturally) to connection negotiation, or ‘conneg’. My weblog, whether HTML or RSS, is my weblog. Same thing, different representation. So perhaps both representations should actually have the same URI, Clients could use conneg to specify which representation they wanted, for example:

RSS 0.91:

[dj@cicero dj]$ GET -H"Accept: application/rss+xml" -Use
Accept: application/rss+xml

200 OK
Content-Type: application/rss+xml

<?xml version="1.0"?>
<!-- name="generator" content="bloxsom" -->

<rss version="0.91">
    <title>DJ's Weblog</title>

Or RSS 1.0:

[dj@cicero dj]$ curl -H"Accept:application/rdf+xml"
<?xml version="1.0"?>


  <channel rdf:about="">
    <title>DJ's Weblog</title>

Or even simply HTML:

[dj@cicero dj]$ GET  -Use
200 OK
Content-Type: text/html; charset=ISO-8859-1

<title>DJ's Weblog</title>

In other words, specify what representation you want in the Accept header. Here’s a quick summary of how (90% of) the Accept: header is used:

As an HTTP client, you say what media types (which roughly translates to ‘representations’ here) you’re willing to accept for a given resource (URI). You can specify multiple media types, and with the aid of a sort of ranking mechanism, you can say which media types you prefer over others, if given the choice. You do this by assigning values, so that “application/rdf+xml, application/rss+xml;q=0.5, */*;q=0.1” means “I’d love application/rdf+xml, but if you haven’t got that, then send me application/rss+xml; failing that, anything will do. The values used are between 0 and 1 (in ascending preference), any media type without a value is assumed to have a value of 1.

So, as a first offering to the Blosxom plugin love-in, I wrote conneg, a plugin with which you can determine the flavour required according to the HTTP Accept header. Here’s how it works:

  1. You define the flavours you want to have ‘available’ via connection negotiation in a configurable variable
  2. In a new plugin event, ‘flavour’, control is given to the conneg plugin to determine the flavour according to the connection negotiation
  3. The content types are determined for each flavour specified, and ‘scored’ according to the client’s Accept preferences
  4. They are then ranked, and the flavour is overridden with the ‘winner’

As you can see from the code, the plugin takes into account what content-types you’ve specified in the ‘content_type.flavour‘ files in your blog hierarchy.

Note I said ‘new plugin event’. There are a number of standard plugin hooks in Blosxom (2.0 beta3). For this ‘flavour’ plugin to work, I’ve added another hook thus:

[dj@cicero blosxom_2_0_beta]$ diff blosxom_2_0_b3.cgi
>   # Plugins: Flavour
>   map { $_->can('flavour') and $_->flavour() } @plugins;

This is in the ‘Dynamic’ section of the code.

I’ll run this new plugin hook past Rael shortly. It’s a sort of chicken and egg situation – I can’t explain the reason for the patch until I’ve done it and written about it. Rather like conneg and weblogs, perhaps. RSS aggregators might not start doing conneg until weblog RSS content is available by that method, and there’s little incentive if no-one’s asking for it. So I thought I’d make a move. Experimental, mind you.

Tiki parser for MoinMoin

Tim Appnel recently created TikiText, a Wiki-like markup language for which Rael recently created a Blosxom plugin. While theoretically interesting, I wasn’t sure how I’d get to know and be able to practise the new markup, as support for it exists currently only in an experimental Perl module to parse and format text that you supply to it.

I’m a keen user of the Python-based MoinMoin wiki (especially at work, where we manage our internal documentation and work collaboration with it), and the ‘natural environment’ for a wiki-like markup language is … in a Wiki. So I decided to mix up a bit of glue; I stuck Tim’s Perl Text::Tiki module into the Python MoinMoin wiki mechanism by writing a very quick and dirty parser, Now I can practice the TikiText markup in my favourite Wiki environment; all I need to do is use a

#format tiki

declaration at the top of a Wiki page to have the glue kick in.

You can see it in action in the demowiki, specifically the TikiTest page. Have a look at the source (with the EditText link) to see the TikiText format.


Blosxom 2.0 Beta1

My favourite blogging software just got better.

Congratulations to Rael in releasing the plugin-enabled 2.0 Beta1 of Blosxom. I dropped it into my cgi-bin directory, tweaked a few things, and it worked like a dream.

One of the plugins available already is RSS 1.0 plugin, which I’m now using to generate RSS 1.0 – see the Syndication page for details. This means I can stop using the old XSLT-based mechanism. Another is the Foreshortened plugin which I’m also using to have a short description generated for the <description/> tag, while the entire content of the post goes into the <content:encoded/> tag from the RSS Content Module.

One thing that strikes me as interesting is the angle in the plugin documentation which encourages plugin developers to respect the Zen of Blosxom and keep its users and platforms (Linux, OS-X and MSWindows) in mind when developing. It’s a refreshing and positive call for simplicity.

RSS aggregators and user-agent information for Blagg

Prompted by a post on the re-awakened WriteTheWeb, I made a small mod to Blagg so that more detailed information is sent in the User-Agent header – announcing that the RSS aggregator ‘blagg’ is the agent requesting the RSS feed.

Following it’s sibling Blosxom‘s philosophy of simplicity and reuse of existing tools, Blagg uses ‘wget’ (or ‘curl’) to make the HTTP call. Adding the appropriate option to the string in $get_prog, e.g. by changing from this:

my $get_prog = 'wget --quiet -O -';

to this:

my $get_prog = 'wget -U 'blagg/0+4i (wget)' --quiet -O -';

was all that it took.

(In fact, personally I’m using my ETag-aware version of wget so I made the change in that small script, rather than in Blagg itself.)