I've been thinking about CamelBones. The fact is, I'm just not happy with it. Well OK, I'm not very happy in general - I'm still struggling with ADD and depression. But personal problems aside, I think that the overall design, to put it bluntly, stinks. I can say that without being rude, because I designed it. :-)

First, a little history. When I began CamelBones, it used a shared framework that had to be installed in one of the various Frameworks/ directories. The framework itself was compiled against a particular libperl version. It wasn't binary-compatible with any other libperl, and so it was tied to a particular OS version for that reason. Apps that used the framework however, used only its "public" face, so they could use any OS version, so long as the correct framework for that OS version was installed.

A number of people (myself included, to be honest) weren't entirely happy with asking their users to install a 3rd-party framework. They (we) wanted to support 100% self-contained, drag-and-drop installs. So, I devised the current scheme as a workaround. The framework is now included in the .app bundle, so there's no need to install it separately. All of the libperl-specific code is contained in a set of separate "support bundles," which are also included inside the framework. The framework examines the system when it's first loaded, and loads the appropriate support bundle.

The problems with the workaround became apparent over time. First and foremost, in order to work on any given OS version, the framework that's bundled in an app has to have the support bundle for that OS version's libperl. That led to the Tiger version of CamelBones being released months after Tiger itself, and to the current lack of Leopard support. Additionally, having to build against a variety of Perl versions makes the build system absurdly over-complicated. In addition to the obvious maintenance nightmare, the byzantine build system also presented a huge barrier to entry for anyone who wanted to help contribute to the project.

So, while I could conceivably cobble together a working Leopard build of the current design, I don't really want to. For one thing, the build procedure is as much of a pain in my own ass as it is in anyone else's. And for another, it won't solve anything; the cycle will simply repeat itself in June, the rumored release date for Snow Leopard.

So, I've decided to refactor the design, and break it in two.

The first part will be the Perl module, which I'm tentatively calling Mac::BridgeSupport. It will compile and install just like any other CPAN module, and will in fact be available through CPAN - I have to use my PAUSE account for *something*, right? As the name implies, it will use .bridgesupport files to export the contents of various Objective-C and C frameworks, making them available from Perl code.

The other half of the project will be the embeddable framework. This will be static-linked against the latest libperl.a, to make it entirely independent of the system libperl. The framework's job will be to present an Objective-C interface for the embedded Perl interpreter.

So, before I start writing and rearranging code, what do y'all think?

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net