Web browser features

blech and I have been talking recently about things that web browsers really should do. We both get annoyed when browsers won’t save the state of opened windows (pith helps here for our web browser of choice, but that’s not the point. It should be app-level – Galeon was superb in this respect.), but there’s other, smaller, things that browsers could do to help people.

For a start, they need to understand the concept of a ‘dirty’ (changed/unsaved state) window, and prompt the user if they try to close it, in the same way that you can’t just close a changed document. Changing data in a form makes a window dirty. A page that’s the result of a POST request is dirty. In short, if I’m looking at state that can’t be retrieved from a bookmark of the current page, the window is dirty.

Form field contents should be remembered completely. Safari is very good about this already, and does some clever tricks somewhere to figure out which forms expect, say, my email address, and fill it in automatically. IE does this too, and it’s a good start. But I’d prefer every form I ever fill in to have it’s state remembered by the browser. I want to bookmark a page with filled-in forms, and have them stored in the bookmark. And I want to hit ‘back’ and have the forms still filled in with whatever I left in them. The number of times I’ve put something long and complicated into a webmail client, hit ‘send’, seen a timeout error, and lost what I was writing forever… I have the habit of putting the contents of big Textareas into the clipboard before hitting the submit button. This isn’t the habit of a man with working technology.

2lmc , as always, have an opinion on this, which is what sparked this ramble off.

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.

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.

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.

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;

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.

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..

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.