CGI::Wiki::Kwiki

Well, in the end, rather than fold my code into CGI::Wiki and its example scripts, Kake has persuaded me to release the thing as an actual module. So, the world now has CGI::Wiki::Formatter::Kwiki and CGI::Wiki::Kwiki. I’m not sure about the name of the latter, but given that is was mostly written as a Kwiki importer and front end, it made the most sense. I hope that people also realise that it doesn’t have to have anything to do with Kwikis at all, and can be used as a stand-alone wiki front end..

They still have very small version numbers, the formatter needs code, tables and comments, and the Wiki front-end needs tests (bad me), but as far as I can tell, for the most part they both work. The code is much cleaned up from the “last release”:/blog/programming/CGI-Wiki, all modular and everything, I’m much happier with it now.

You can get them both from CPAN.

build_m3u

I was reading this article on m3u files and decided to scratch one of my long-term itches, building a decent windows playlist on the file server. It’s a.. large collection, so I don’t want to build things on the client end, you see, it takes bloody ages.

Up till now, I’ve just created a list of paths, and used that as the playlist. This had 3 disadvantages:

  • it’s very hard to have it sorted by anything useful, using the filename is hopeless as there are several different naming conventions involved. blech’s fault.
  • I’d quite like to have the track lengths already by the tracks when winamp starts, as opposed to have it add them whenever you see them.
  • for some reason, winamp starts much faster when there are EXTINF tags in the playlist file. Don’t know why. Don’t care.

So now I search the server for files, read the id3 tags, sort by artist/album/tracknum/title and print out, along with the track length and name in an EXTINF tag. The whole process takes almost exactly 2 mins, but it’s not very memory-efficient. For various complicated reasons the server has almost a gig of memory in it (ok, they’re not complicated reasons – we just don’t own any other boxes that can use the stuff) so I don’t care about this.

code is here, if you care. It’s hard-coded for my server, but the only thing you’d really need to change is at the beginning, where $root and $remote are defined – $root needs to be where the music lives on the server, $remote is where it lives on the network. For my server, I samba share /music on the server cowboy as cowboymusic. Also, $playlist should be where you want the playlist to go.

broken tick

I’m releasing another Bot::BasicBot at the moment, to change the semantics of the tick() method. Instead of getting called every 5 seconds, you now need to return a value from the tick() method, and you will be called again in that many seconds. this is waaay more useful than before, but of course it’ll break anything that uses it. Oops. But 0.2 has only been out a short time, so I should get away with it.

More of a problem is what to do with Bot::BasicBot::Pluggable, because I now can’t just pass the tick method straight through. I have a new version in CVS that I’m very happy with, needs more tests, though, but the feature still stopping release is per-module tick events. I want every module to be able to have independant tick events, instead of sharing one global tick, but haven’t come up with an elegant way of doing it yet..

Bot-BasicBot-Pluggable 0.04 released

Hah, finally I bullied simon into releasing Bot::BasicBot 0.04, allowing me to release a version of Bot::BasicBot::Pluggable that actually installs and builds and works. Thanks, Simon. I’ve bumped the version number to keep in sync with BasicBot, not totally sure why, as I suspect I’ll rapidly overtake it, but I’d like to get >10E-1 at some point…

Anyway, read the docs, or download the code, send me feedback.

blogroll

Ah ha! I have a blogroll. Ph33r me.

In other news, Template::Plugin::XML::Simple is really nifty.

<p class="code">
[% USE blogroll = XML.Simple('/export/home/tomi/web/jerakeen.org/blogroll.opml') %]
&lt;p class=header&gt;blogroll&lt;/p&gt;
&lt;p&gt;
[% FOREACH section = blogroll.body.outline %]
  &lt;a href="[% section.htmlUrl %]"&gt;[% section.text %]&lt;/a&gt;
  [% UNLESS loop.last %]&lt;br /&gt;[% END %]
[% END %]
&lt;/p&gt;

Blogging and Content Management

I’ve been toying with architectures for the Ultimate Content Management Application, a bit of vaporware that’s suffering from Second System Effect before I even come up with a coherent plan, and to do this I’ve been looking at content management systems. Well, ok, I’ve been trying to look at content management systems, because almost everything I find that a) calls itself a content management system and b) is free, is not a CMS, it’s a bad slashdot clone that lets you take the dates off the entries. I’m sure there’s more to content management than there is to a blog, but I can’t find any evidence to the contrary. Of course, there might be expensive things out there that do what I’m imagining, but nothing I can download. Which is no bloody good, I want to play with a Real App.

This is in weird contrast to this megnut which complains that most blogging engines are bad content management systems that let you display date-based lists of entries and call themselves blogs. Weird. So, are there any CMSes out there I can play with? Preferably written in perl…

thanks to blech for the megnut link.

Blog-Mail convergence

Muttley caused this train of thought. Blame him.

Thoughts for a blogging toy

Here’s something I might do. Every time I post a blog entry, people on a list could get a mail with the subject, contents, etc, just like I actually just sent the thing to a mailing list. People can reply to the mail, and their replies get put as comments on the blog entry, as well as mailed to the rest of the list. People posting comments from the web page, their comments go out to the list. So if you ignore the mail aspect, it’s a traditional blog, and if you ignore the blog aspect, it’s a traditional mailing list, albeit with the caveat that only the owner of the blog can start a thread. And hell, that’s optional, you could allow free posting…

Once you do that, of course, the blog could be viewed as merely a web based archive for the mailing list, just with a much nicer web interface than most mailing list archives. Blogging software has put a lot of effort into managing date-based information archives, much more than mailing lists. On the other hand, mailing lists have put much more effort into managing threaded conversations than blogs have.

This blurs the line about what it is, of course. I’d probably initially implement it as a blog, with a bit of mail glue attached, but I suspect the more elegant way would be to have a mailing list with a very sophisticated web archive attached to it, one that handles threads as entries, and that allows you to post to the mailing list through the archive page. The distinction between the two rapidly becomes moot, of course.

Hmmm. Must play with siesta

(later) More Rambling

So, muttley has rambled as well. Interesting. He has some ideas about multiple blogs tying together somehow that I’m not seeing a way of making work in my head, and I hate talking about things I can’t construct a nice working mental model of, but he’s right, it would be nice to have a system of mutliple blogs tied together. Like this.

You get thread ownership problems, though. As things stand, I control a conversation on my blog completely. (well, if I had comments working yet…). That’s ok if the blog is also a mailing list, because I’d control the mailing list server completely as well. But if, say, threads I started were hosts on my blog, and threads paul started were hosted on paul’s blog, we get issues of potential censorship, and people picking the thread to comment on based on who’s blog the start thread was on.

That issue asside, it’s quite easy to adapt the first model espoused above to this sort of thing. All the participating blogs would send stuff to the same mailing list, and the mail reciever would use some smarts to determine which mails were replies to which blogs, and post comments appropriately. All doable. For the second, more elegant, solution, where the blog is merely one way of representing the ‘message’ objects that the back-end understands, we’d either need to host all the blogs in one place, or have a distributed server, or something. Not sure.

Tell you what. I’ll actually implement something at some point, and we’ll see how easy the collaborative stuff is then.

AudioFile::Identify::MusicBrainz

After much muttering back and forth between blech and I, I have written and released AudioFile::Identify::MusicBrainz. The old MusicBrainz client relied on the C library they distribute, which was silly for something that sent and recieved pure RDF, so a pure-perl implementation was just begging to be written.

So, upsides, it works, there’s exactly one sort of query you can send it, but that’s fine, it’s the important one – you can say ‘I know this about a track, tell me more’. The next step is to give the user a nice choice, and then let them write the updated information back into the ID3 tag.

Downsides, I’m not using ‘real’ RDF parsers, I’m using XML::DOM. This worries me, frankly, I’d much rather do the right thing, but I get a headache trying to make the perl RDF stuff work. There’s an RDF::Simple out there now, though, so maybe I’ll try that…

I’m going to get a reputation here for stupidly long module names, you know.