Friday, November 11, 2005

AppleScript adventures: updating a client iTunes library when tunes are added to a server iTunes library on the same machine (fast user switching)

Aeons ago I wrote Fortran for food during summer break in college. Millennia ago I wrote a utility in C to translate MEDLINE feeds into a form I could import into a database. Now, in my extreme dotage, I have revised an AppleScript that supported updating a client music library one one machine from a master music library on another machine. I did this so both my wife and I could sync our iPods to a shared music library, but keep our own playlists and sync contacts and calendar items correctly.

The revised version differs in seemingly minor ways -- I had to remove 2-3 lines and add 3-4 lines to implement Apple's "new" (introduced in 10.3 but only sort-of-worked in 10.4) support for sending messages to a specific user session. This would have been a trivial task, even for someone like myself who knows nothing about AppleScript, except that there's zero documentation for this new functionality. I got a key tip from a super AppleScript expert -- who gave me the morsel but made it clear I was not to bother him again (I won't give his name out -- he must get these kind of pesky requests hourly and I don't want to add to his pain).

I'll revise the script over time and put it someday in a proper web page, or submit it to the iTunes AppleScript repository. The behavior is pretty ugly however, which suggests whyApple hasn't documented this function. Some background, then the explanation.

It turns out that AppleEvents were all designed with the understanding that there was one instance of an application running on a machine, and that application was available to any authenticated request. Introducing multiple instances of applications seriously messed this up -- in ways subtle and complex. A lot of remote control solutions for iTunes, I now realize, are going to run into this problem. From a few hints I found in my searching, I suspect the behavior of client requests may be unpredictable with multiple AppleEvent targets. It is noteworthy that these events will be processed only when the requester has an administrative username and password for the receiving machine.

So why isn't this documented? A few reasons come to mind:
  • this may still be quite buggy and have very nasty side-effects
  • the user requests need to know the userid (3 digit number) and the process ID for the receiving application. There's no elegant AppleScript friendly way to get these; the only method I know of is 'choose remote application' which brings up a dialog that requires an uber-geek to manage and that is buggy besides. (The Bonjour method doesn't work at all.)
  • it is a very bad security practice that an admin uname and password is required. For all I know these are sent clear text.
So Apple has a partial solution in place, but it is very partial and probably somewhat embarrassing. I suspect there won't be anything better until 10.5. (I think 10.4 will go down in Apple history as very much a 'transitional release'.)

No comments:

Post a Comment