Trail: Home >

Goals and Ideas

Here's a collection of goals and ideas for the Cowry project.

Multi-component Applications

Bundle packaging is fine when what you're packaging is just a single application. But when your software package actually consists of an application, a framework, several plugins and a preferences pane, you'll have to use an installer after all. In most cases that also means your application is no longer self-contained, and un-installing becomes tedious, too.

The ultimate goal here is to allow all components of a package to reside within the application bundle, and have the Cowry system track the components and take appropriate maintenance steps automatically. The user should be able to run applications right out-of-the-box, and be able to move them around the file system as she likes.

Delivery

A bundle appears as a single file once it is on the target computer, but getting it there is somewhat difficult, since technically, it is not a single file. Today, most Mac applications are delivered as disk images that are downloaded over the Internet. The user then double-clicks the image to mount it, and drags the contained application to a folder on the hard disk.

Some applications are packaged using other general-purpose archive formats, including StuffIt, ZIP or the Unix-style .tar.gz. Installing such an application still requires the user to de-compress the archive, then drag the resulting application into place.

To improve this, the Cowry system would use a widespread archive format (.zip or .tar.gz), but give the files a different file extension. Double-clicking such an archive would open the Cowry application, present some information about the application, then ask for where to install the application (e.g. system-wide in /Applications or just for the current user).

Since no application code is executed until the user acknowledges the installation and actually runs the app, it would be safe to have the web browser open the archive automatically after downloading. (This is not the case with disk images, which may contain malicious code that automatically executes as the image is mounted.)

Automatic Updates

Many Mac applications today have a built-in function to automatically check for updates. There are several problems with that:

The check may be crudely implemented, causing all kinds of problems.
Only very few applications will let you set an interval for the checks. Instead, they'll just check for updates when they're launched, which can be too often (think StuffIt Expander) or too far between (think Quicksilver), depending on the application.
Some applications have a "Check Now" menu item, some don't. In any case, you'd have to launch all your applications and click that item to do a full check-up — if you've disabled automatic checking, that is.
Many applications don't care whether the check will cause your modem to dial out.
When an update is detected, most applications just display a notification dialog and send you to their website. Only very few actually unpack and install the update for you.
You'll have to trust every application with network access. This should be considered an issue whether or not you're using firewall software like Little Snitch. You cannot be sure what other information the application passes along as it "phones home" to check for updates.
There is little consistency between different applications.

The solution is clear: Remove update checking from the individual applications. Instead, put the necessary information inside the bundle in a format that can be read by a generic, external updating application. Any feature implemented there would automatically benefit all applications.

Documentation

Help books for the Mac OS X Help Viewer reside inside application bundles. Many developers also include their ReadMe and License files inside the application, making them available from the Help menu. There's only one problem with that: users must run the application to access the documentation. So some developers put another copy of the ReadMe or documentation on their distribution disk images, outside of the application.

To avoid this duplication, Cowry could provide direct access to an application's documentation using a Finder context menu extension. The Cowry framework would also include library code to display ReadMe files and other documentation files inside the application, plus code to show welcome messages on the first run.

Unix Software

Mac OS X uses bundles only for GUI applications and Mac-specific packages. Command-line Unix software is still organized in a traditional Unix directory tree, invisible to the casual user. Mac applications that include supportive command-line tools need to install these in some way. Cowry could solve that problem by tracking the locations of the bundles containing Unix items, maintaining symlinks in a designated directory and adding that to the appropriate environment variables (e.g. PATH).

Cross-platform

While Mac OS X supports bundles per design, other popular platforms do not. One goal of the Cowry project is to make the bundle mechanisms available on Unix platforms as an alternative to traditional package manager formats like .deb, .rpm or .pkg. Eventually, Cowry might even spread to Microsoft Windows platforms.

Build Tools

The build tools usually used in the Unix world — make, autoconf, automake, libtool — aren't really helpful when you're packaging software for distribution. They also have lots of private problems and significant inertia when it comes to supporting new platforms and features.

A build tool that has full knowledge of which files make up the package, how they are built and where they should be installed could ease the lives of developers, packagers and users alike. It would also ease building bundles instead of traditional packages, and could support building Mac OS X style frameworks for library packages.

Work on such a tool was spun-off into a separate project named pond.