The answer my friend, pops up to tell you when someone drops a file in your Drop Box!
Well, us, really.
Since I never felt comfortable telling people to run Apache as their user (which is giving a web server read-write privileges to everything you have those privileges for!) I’ve been searching for another way to poll iTunes for info and send commands to it via a web interface, because the www user (Apache and PHP) can’t do it directly through AppleScript.
In searching for a solution, I found
Brian D. Foy’s excellent article MacDevCenter.com — Build an iTunes Remote Control on using a shell daemon to read a temp file and pass what it finds to osascript. I tried out his scripts, but (under 10.4, at least) the daemon script’s process name is bash, making the companion script used to kill it worthless. So I says to myself, “Self, looks like you’re gonna be learning some Perl.”
Wrong. I’m lazy, I admit it. But I have a very good reason to make this project easier: Folder Actions. A daemon that already runs and performs any AppleScript you can write based on the conditions you give it.
What now? I’ll tell you what now.
- Scrap the PHP “exec(osascript)” from the current package.
- Write “tempnam()” routines for the control input that write commands to a file. The file name will include the user name (taken from iTunesDSr “pwd”) so the next step can use it properly.
- Write a Folder Actions script that runs when a file pops up in the tmp directory. If it’s an appropriately named file, it will read it and pass the commands to iTunes.
- If possible, use this same Folder Action to write a file containing iTunes current info, another file for all playlist names, perhaps another with current playlist track names. If not, write a companion, stay-open AppleScript app that can.
The hard part, perhaps even a sticking point, will be timing these scripts so they fire when needed, but not after the next step in another script has passed. In first tests, the PHP tempnam() routine must sleep() for 2 seconds to give Folder Actions a chance to see the file.
Given that, this method will be more sluggish than what I wanted it to be. But if it keeps some a-hole, or some worm from reading your user files (or worse), it’s well worth the inconvenience.
Thanks to brian d foy for correcting my mistake on citing his Perl article (MacDevCenter.com — Controlling iTunes with Perl) and for pointing out the Perl extension Mac::AppleScript (Mac::AppleScript – Perl extension to execute applescript commands on OS X – search.cpan.org). If this project interests you I suggest you check it out.