AC Capehart/WordPress and Audiotron

Created Tue, 06 Dec 2005 07:08:53 +0000 Modified Thu, 14 Oct 2021 14:31:47 +0000
792 Words

This is a geeky post. Non-geeks may safely skip over this post and still have a full breadth of understanding of my life (and Sam’s, and to a lesser extent Carolyn’s), or at least as full a one as can be had from this blog.

There, now that that’s out of the way, let me fill you in on what’s up. I’ve seen a few blogs (mostly LJ, but some others) that have a “mood” emoticon, and a little “What I’m listening to” bar wherein users can type in the tunes they are currently jamming to. I thought it was a neat idea, but could reasonably be taken a step further. I’ve already mentioned that I now own an audiotron. Well, one of the cool things about the audiotron is that not only does it have a web user interface, so that I can control it anywhere in the house where there’s a web browser, it also has a web-based API. Naturally, I thought “OK, I can write a wordpress plugin that will query the audiotron, ask it what it’s playing, and add it to the wordpress site.” So, I did. Right now, it only puts the information on the admin pages like the “Hello Dolly” plugin, but that was fine for proof of concept.

The problem is one of latency and persistance. To get the currently playing information from the audiotron takes about 30 seconds because the audiotron doesn’t play nice by putting things like content-length in the header. This means you have to wait for it to close the connection before you know you’ve received what you’re going to receive. Needless to say, waiting 30 seconds for each wordpress page load just to see what’s playing on the audiotron is, in a word, stupid (and just a plain old pain in the ass).

What I want to do is run separate threads. One will display whatever information my audiotron object currently has, and the other will update that object every N seconds for some N greater than 30. But that just doesn’t work in the web model of “open->request->response->close”.

Besides, PHP doesn’t seem to have threading. It does, however, have process control. Regardless, I don’t see how even forking out would really take care of this for me in a non-persistant web environment.

Besides, as the PHP process control documentation states:

Process Control should not be enabled within a webserver environment and unexpected results may happen if any Process Control functions are used within a webserver environment.

So, the only thought I have is to take the risk on forking within a webserver environment, saving the child_pid to the database, so that future requests can see that there is already an updater process running. That leaves an updater request process running after the parent process has died. Which gets us into zombie land or at best, adoption by “init” — both of which seem messy to me.

The other idea I had is cleaner, but produces a less interesting result: Pull the audiotron object from the database, show it’s data and then fork an update (or otherwise do it at the end of the page). That way, at least the user gets the whole page, even if they are left “spinning” for 30+ seconds. But it’s no longer “What’s playing in my audiotron”, it’s “What WAS playing in my audiotron the last time someone hit one of these pages.”

I dunno. Anyone have any suggestions about how to crack this nut?

Oh, and if you care, you can download the plugin here.