jerakeen.org

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.

useful things that rendezvous should be able to do:

• detect an SMTP server and set Mail.app or whatever client you’re using to send through it
• Detect the equivalent of a Domain Server, and add a ‘log onto local server’ option in the login screen that will pull down a profile from a server, so you get workgroup functionality merely by being on a local network with a workgroup server
• I want iCommune back, but in a way that works.

I also really want these things to work from non-apple machines as well - I want the server at home to advertise the house music collection and SMTP server, despite the fact that it’s a linux box. But that’s harder to whinge about.

from a conversation with blech.

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.

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.

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.

blech has been on at me recently to finish my half of our evil ‘Wire and string’ project - it’s a cunning, cunning plan which we really should put more effort into. Anyway, here’s a heap of self-congratulation that I’m done, and he should get off his butt and implement the other half.

Essentially, the problem is as follows: We have a computer in the lounge that can play music, hooked into the network and the stereo system. But there’s a complete lack of decent software to control the thing. We searched and searched, and all the interfaces we could find sucked.

Now, the best music control interface we know of is iTunes. We want iTunes to control what is being played on the lounge machine. But it’s not a mac. Hence the goal - have iTunes on a mac locally, pick up what song is selected/playing, and send that to the lounge computer, which will then play it through the amp. blech took the iTunes half (the Wire), I got the server half (the string).

Now, there are no non-awful MP3 playing interfaces for perl. None. Almost everything that I could get to compile at all (and didn’t need non-free libraries you can’t download any more) wrapped either mpg123 (now that’s a pretty web page) or xmms. The mpg123 wrappers seemed to be the best bet, and for the most part they work, but there are… issues. I didn’t get proper events for songs ending or stopping, it was quite easy to wedge the thing to the point where you couldn’t control it any more, etc, etc. | believe these are limitations of the command line mpg123 interface, and I can work round them, but I don’t want to have to patch the source code just to get a working system, and it makes distributing things a complete pain. I also need the server to be absolutely robust, it’s no good having to SSH in every 5 mins to fix the server - the whole point is to avoid having to think about it.

Wrapping xmms isn’t much of an improvement. It’s got a much nicer interface to control it, but, of course, it’s controlling xmms, which is a seperate app that needs to be running, and it needs to be running on a machine with an X server. Hard, given this is a headless server.

But, in the end, that’s what I used. I was saved by Xvfb - I can run an X server on the machine without having to worry about graphics cards, and launching xmms from the cgi is possible, so it will run as the right user and everything. After a lot of messing with annoying permissions, I have a CGI that will make noise.

The other problem is that the Mac only knows where the music is on the machine locally. Rather than having the iTunes end convert the local path into something the server knows about, I take anything that might possibly be a path to some music, and trim things off the left of it till the right hand side matches something in the ‘locate’ database. Disadvantages - you need an up-to-date locate database. Advantages - you can pass just about anything that is music, and the server will have a shot at playing it. In practice it works really quite well.

So, yeah, code . w00t.

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.

blech and I were bored, so we played with FileVault. And it’s shiny. As long as you’re on the local machine, it all works transparently. When you have FileVault turned on, your home directory contains a single file, {username}.sparseimage. This is a standard Mac OS X encrypted disk image, certainly I can just mount the thing using a different user no problem. When you log in as a FileVault user, your encrypted image gets moved to ‘/Users/.{username}, and the sparseimage is mounted in your old home directory. When you log out, this is all undone. Pretty nifty.

Aside from the encryption, which is nice, the main benefit I see here is that suddenly your home directory is a really nice, easy-to-back-up .sparseimage file on it’s own. I’ve been having problems recently trying to find a nice way of backing things up, and this might be it. Slight worry is that only Panther can mount the .sparseimage, Jaguar has problems, so restoring needs a fairly recent machine. But I can live with that. I ph33r what will happen if I try to back up the image while I’m using it, though, so I’ll probably have to log out and in as another user to run backups. Which will be annoying, but bearable.

The next thing we wanted to try was network access. And this is where things get not-so-nice. Essentially, it looks like the process above is the entire system, other than the nice GUI to turn FileVault on and off. When you connect to the home directory using AFP or Samba or something, and the user is not logged in on the local machine, you get a folder containing one file, the disk image. Not very useful. If you have Panther, of course, you can just locally mount the image at this point by double-clicking on it. But that’s 2 steps, not very Applish. And of course, on any OS other than Panther, you’re out of luck, Jaguar can’t mount it, and Windows / linux don’t stand a chance.

If, when you log in, the user is logged in on the local machine, you get their home directory, and I should point out that this is their home directory being sent unencrypted over the wire. Not good if you had paranoid reasons for using FileVault, which will be most people.

Of course, I can’t think of a nice, simple, elegant way of having this do the Right Thing. The best we could come up with is that a Panther system should realize it’s connecting to a filevault home directory, and remount the .sparseimage locally again, so that the only thing going over the wire is encrypted disk image. This has the advantage that you could host these things on a linux / Windows server as well. But I have no clue how you do locking on a .dmg, it sounds too horrible to contemplate, so you’d need a way of negotiating with all the other clients so they couldn’t mount the drive at the same time.

So yeah, the current system has the advantage of being very simple, and Just Working. But not having network access to my home directory unless I’m logged in will be annoying.