02.08.08

The Initial Developer of the Original Code is

Posted in Camino at 1:31 am by Smokey

…the author of this post.

The title is a line from the license headers that are included with every new source file included in the Mozilla source code repository. While many people contribute lots of code to existing files, only relatively rarely does someone get to add an entirely new source file (and through that become an “Initial Developer” under the terms of the Mozilla Public License). Most often new files come about when someone adds a “major” new feature to a an application, which brings me to the next part of this post.

Tonight I checked in code that successfully enables Camino to build and ship support for passing RSS and Atom feeds to web-based feed readers (Bloglines, Google Reader, iGoogle, and My Yahoo!) for Camino 1.6. This is the most significant feature I’ve added to Camino (and the only one that wasn’t largely project and build system changes).

Observant readers (or those addicted to Bonsai) will notice I used “successfully” above; tonight was actually my third attempt at enabling the web-based reader support. Last Friday I initially landed the code, only to discover that osacompile on Mac OS X 10.5 supported UTF-8 source files while osacompile on 10.4 did not. I also happened on a problem where unify would sometimes choke on the .rsrc files osacompile compiled. In the process of discovering those problems, I also learned how to play with Mozilla’s CLOBBER support in order to clean out the broken feed handler applications that were causing unify, and thus the build, to fail.

On Tuesday night, with those problems fixed, I again tried to enable the code, only to discover another problem—unify was finding differences between the compiled .scpt files on the Intel and PowerPC architectures. After some investigation, I guessed that the latest problem was triggered by osacompile finding a different existing Camino when compiling for each architecture. Thanks to Mark Mentovai and Peter Jaros, we arrived at a solution that avoided causing osacompile to reference an actual Camino application at compile time and produced a script that ran on Mac OS X 10.3.9 through Mac OS X 10.5.1 (all of which ✈ will support).

For those of you who want no more technical details , please enjoy the integration between Camino’s feed detection and your web-based feed readers! Special thanks go again to Mark and Peter for their help and reviews during the entire time I was working on the bug (and for Mark’s Makefile magic that solved the very thorny issue of creating multiple feed handlers automatically from the various input files).

For those of you interested in the technical side of the solutions that fixed the problems our tinderboxen were having with unify (the script that produces Universal binaries from two single-architecture binaries) and its interaction with products generated by AppleScript’s osacompile, here are the nitty-gritty details.

The first problem we solved was related to the .rsrc files included in each applet. For reasons that are well beyond my grasp, sometimes, but not always, the .rsrc would differ in ways only unify could see. The fix for this was quite simple; just DeRez the data fork of the .rsrc and then Rez the result back.

The second problem was more thorny. AppleScript likes to store a reference (including the full path) to any application mentioned in a compiled script. Unfortunately, on the tinderbox, new Camino applications are constantly created and destroyed, and with a Universal binary build, there will be more than one Camino. Combine that with the fact that LaunchServices will treat the copy of the application with the highest version number or the most recent timestamp as the “canonical” copy of the application, and you get a nightmare: each time osacompile runs, a different copy of Camino will be the “canonical” one. We had to come up with a way to refer to Camino indirectly, so that the compiled AppleScript would not attempt to find Camino until runtime.

If you are only looking to run on Mac OS X 10.5, this is very easy; you can send commands to an application using the application’s bundle ID (e.g., org.mozilla.camino). On 10.4 this capability isn’t present, except with a somewhat clumsy series of commands. However, on Mac OS X 10.3, that code errors when it runs; AppleScript’s support for the bundle ID is even more limited there. After banging my head around ways to make the code run on 10.3 without referencing a path (my standard work-around for indirect references on 10.3 is to get the path by means of the bundle ID, but in some cases the old-school bundle signature, a.k.a. the creator code, can also help you out on 10.3—unfortunately, not in this case), Peter finally suggested I define “Camino” as a property and then use the property when sending commands; success!

If you ever happen to be in either of these situations—and I hope you never will be—perhaps these tips will be useful to you. In any event, Peter’s solution struck me as clever, and I hope now I’ll remember it the next time I’m faced with some thorny application-referencing problem.

Permalink