Deploying Frameworks

If Arnold knew he'd be royally pissed.

Get It Try It

A long time ago there was a pinhead of a programmer named Arnold. Arnold worked alone. He was very good. Thanks to him we've made great discoveries in computer science.

Arnold had this fantastic routine he called 'screnching': he could take two numbers and do fantastic things with them. Everybody would ask him 'Arnold how could you do those fantastic things in your program?' And Arnold would reply 'I scrench things'. And then they'd ask Arnold what 'screnching' was but he wouldn't tell them.

And every project Arnold had he'd find he needed to scrench numbers again. So he'd dutifully write in the code in his project.

Arnold was very productive and wrote ten times more programs than anyone else so this typing in of the scrench routine became a bit of a bother. So one day it hit Arnold: he'd save a separate file with his scrench routine and just copy and paste it in when he needed it.

So much better.

Then things took a new turn for the worse because Arnold was so much faster than before and consequently he was given even more programming projects. So he needed to find a way to streamline things even better.

And he figured out a way. Of course he did - he was Arnold! So instead of copying and pasting his scrench routine every time he'd just include it as a source code file and then the compiler would compile it like the rest of the code - WHOOSH!

And things were better again - in fact even better than before - that is until the bosses noticed Arnold's heightened productivity and gave him even more to do.

That compiling of the scrench routine was wasting time, thought the ambitious Arnold. I've got to find a way to make things go even faster. And so he did.

Arnold created a separate project that only compiled the scrench routine to object code. No program here - just an object module. And then he included the object file in his projects instead. Now the compiler was blazing! And Arnold set new speed records again.

But hey, thought Arnold, what about the day when I have more than one routine like scrench I want to use in all my programs? What do I do then? That night Arnold didn't sleep well. He kept tossing and turning, thinking of all the thousands of small routines he'd have, an object file each one, and each of them would have to be included in each and every programming project he made. Too much work, thought the sleepless Arnold.

The next day at work he created a LIBRARY. Arnold.lib. He put his scrench routine in the library and the library was a separate project he kept to the side. Any time he wanted to add further routines to it he could. And the magic of this was that no matter how many routines he had in his library he needed only one include in his projects: Arnold.lib - the library itself. Everything else took care of itself after that.

By now Arnold was becoming quite the hacker and started thinking about other things such as efficiency. And as there were hundreds perhaps thousands of Arnold programs out there and each and every one had the scrench routine baked in Arnold started having nightmares about how much code that same single routine was taking up on people's disks worldwide. Arnold couldn't have that - so he came up with yet another invention.

Yes it's true: Arnold invented the SHARED LIBRARY. The idea was simple: the reference to scrench would be resolved not at link time but at run time. When the program loader picked up the program it would see a reference to scrench and its library; then go find the library; then map the address of scrench into the address space of the program; then it was all systems go.

In this way Arnold's programs wouldn't all have the scrench code in them anymore - in fact NONE of them would have the code! The scrench code would live by itself, comfortably ensconced elsewhere on the computer hard drive. The program loader would find its location at run time and take care of the rest. Brilliant!

Arnold set to work and regressed through his hundreds and thousands of programs and rebuilt them to use a shared library instead; then he called all of his clients and told them the news: they'd save SO MUCH DISK SPACE with the new release!

Most clients were overjoyed: their hard drives were bursting at the seams with BitTorrent movies and porn stashes and if Arnold could save them a little disk space - then go Arnold! So everyone gratefully accepted the new update.

*

A while back a blogger was commenting on the sporadically discussed issue with OS X frameworks. He cited the Sparkle framework, a freely available bit of code that can alert users to upgrades of their applications by checking with a remote server.

The blogger remarked he'd seen this half megabyte framework in twenty three apps he still had on disk. Sure it's wasteful, he said, but at half a meg each time it's not really that much disk space.

He's missing the point: it's OK for him to say it's a level of waste he's prepared to live with but it's not OK for developers to say so. It's not their disks to deal with - those disks belong to their users and they can't be so presumptuous.

Common sense says if you have a useful framework you make the single copy of it available to all. Certainly this is what the OS vendors are doing: no app on OS X embeds the Cocoa, Messaging, WebKit frameworks: they're found instead in globally accessible locations. And programs dependent on them take those precise locations into account.

There's really only one reason to embed a framework in an application: it's easier for the programmer. But by definition what's easier for the programmer doesn't count - what counts is what's better for the user - the customer. And there's no customer yet found who will say 'oh so you're using ten meg too much disk space? Thank you! Thank you so much!' Ceteris paribus it's the other way around. Strange, innit?

You only would want to embed a framework if it simplifies your own work. If you have a project with a framework but that framework is never going to be used anywhere else and you know it there's really no point in keeping it as a framework - that only slows the app down and makes it bulkier. If the code's not exportable and globally useful then it belongs in the application. Period.

If however you find a few useful routines and think they'll come in handy further down the line then you export them - to a framework. And unless you're insensitive to your customers you make sure they have one and only one copy of that framework on their disks no matter how many applications they purchase from you.

The trick is in getting that framework where it's supposed to go. Already vendors are going to great lengths to make things appear to be easier than they are. DMGs are used along with fancy graphics appearing only in Finder of course with arrows THIS BIG pointing to '/Applications'. Of course this is not the optimal destination for a download but who cares. A big arrow and then 'drag this to your Applications folder'. Said and done. It's supposed to be easy like that. Adding another level of complexity by supplying yet another arrow with the caption 'drag this one to your /Library/Frameworks folder' is just too much.

Of course you could use an 'installer'. Such as Apple's. That works fine - as long as the routine used is tested well. The tales of woe in conjunction with misbehaved installer routines are myriad. You're taking a chance you're going to hose a hard drive for someone. It simplifies things and lets you put your framework where it belongs but it takes careful planning and meticulous testing.

There's no easy obvious middle ground. ACP users get the bits and pieces with a note of what to do: drag the one blob to /Library/Frameworks and then drag the rest wherever you want - and preferably ~/Applications and not the repository in root. ACP users fare OK because they're mostly IT professionals. And it sounds so easy to only require two mouse drags but it's really a matter of making things as easy as possible.

A long time ago - but not as long ago as Arnold - there was a famous meeting of industry moguls in Las Vegas. Philippe Kahn of Borland was there. So were others in the same boat. They'd come to discuss the new wild frontier: TSRs.

Kahn had just come out with SideKick. SideKick was a Terminate and Stay Resident program. It hooked into the Intel page zero interrupt vector table. It got a look at all the keystrokes (much like those Russian programs do today) before the rest of the system got at them. Then if you for example held down both shift keys at once SideKick would come back up.

When you started SideKick it didn't do much on screen for you - it merely initialised and then Terminated and Stayed Resident. It found a cranny of memory it could use and it just stayed there lurking.

SideKick was big - and made Kahn's Borland into something substantial overnight - but now everyone wanted to get in on the act. The trouble was there were no rules for doing things like this: SideKick just picked some memory because it was all available; what would happen if all the others started doing it too? Would they overwrite and corrupt one another?

Therefore the meeting. Those present at the meeting had to come to an agreement how they were going to maintain order in the TSR business. It was no good thinking 'I'm going in and taking some memory - screw the rest' because the others would be doing the same thing. And then everybody would lose.

The lesson learned in Las Vegas is that vendors have to be aware of one another. They can't act and play in a vacuum. There are other products out there all the time. They have to keep that in mind and act accordingly.

If each and every one of those twenty three vendors with the Sparkle framework had thought 'gee I bet a lot of other vendors are going to use this framework - maybe we better work something out'; if the creator of Sparkle had included code to automatically move the framework to a neutral location on first startup; then things would be fine. And it can be done: Sparkle might not do it but others already do.

One thing's for sure: if you ever embed a framework in your own application and at the very least not move it out on first time you're the only one benefitting - at the expense of your customers who gain absolutely zip.

And if Arnold knew he'd be royally pissed.