[haiku-development] Re: Package manager

  • From: Jack Small <jaxs@xxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 5 Aug 2009 00:36:43 -0700


On Aug 4, 2009, at 8:54 PM, Ankur Sethi wrote:

Since the "bundles" idea seems to be OSX inspired, I'd like to throw
in a few random fanboi remarks (should these go in the Wiki?):

A bundle on OSX is just a folder which you can browse from the
commandline (or open it in Finder through a context menu). Bundles are
used not just for applications, but also for libraries (OS X
developers call them Frameworks) and a few other purposes (like iPhoto
albums). If Haiku uses bundles for distributing apps in the future, it
might be a good idea to have them as simple folders instead of ZIP
files, with metadata stored as attributes of the folder.

I'm new and haven't yet earned a lot of say but this is one thing I have already really missed.

A bundle is quite simply a folder with an extension that has been claimed by an application. Just like claiming a file type, but for a directory instead. The UI represents the bundle to the user as a single "document". It gets an icon if one is assigned and when opened it opens the application the same as a traditional file would. It is incredibly handy.

The top level of the bundle contains a directory named "Content" and inside, depending on the use of the bundle, is more or less free to be used by the developer for storing any sort of resource using the file system to organize. There is also an "Info.plist" XML file that acts as a manifest and a generic set of "bundle" APIs for accessing various useful parts.

A Framework is an excellent example. In the Content folder is a symlink named "Current" that always points to the internal folder with the most current version of the library. The Info.plist for every bundle contains a "bundle id", specified in reverse domain form, as a unique identifier. Then the name and location of the library becomes largely irrelevant, because you can find it by identifier.

The content of a framework can contain multiple versions, each with its own set of content like a "Resources" folder. You can have entire sub-frameworks in the Frameworks folder. You can have multiple platform binaries for a library and all it's tools too. But by far the most useful thing is that you can also include the headers for any publicly defined API right there inside the framework. Calling #include <Framework/FrameworkHeader.h> finds the most recent header if it finds the library. The system headers do not come in the standard install, but instead with the developer tools, as end users have no need for them. And probably for the sanity of developers who spend a lot of time in frameworks, they are not represented as single elements but instead left as folders. AFAIK this is the only exception to the "single document" illusion.

Every modern Mac application is actually a .app "package" as well. That way, all your resources and additional items like documentation and plug-ins can be files (or bundles) inside the app. No matter where a user puts an app, it is always able to find all it's resources. Things like the "Spotlight" importer - a plugin for indexing app claimed documents. Individual "Preferences" are user specific and saved outside the application bundle.

Take if from a former fanboi: bundles are one actual good thing worth serious consideration. They simplify things for users and enable things for developers that would be very hard to do with a single file & set of attributes.

More later,
Jack



Other related posts: