On Mac OS X, one of the nicest things is how applications are handled by the system. Unlike other operating systems available today, all applications are represented in the Finder (the Mac file browser interface) as a single file. In actual fact, this 'file' is actually a folder which contains all the data the application needs in order to run, unlike on Windows, were a single .exe file can only contain a limited number of resources and larger apps must usually rely on a vast network of .dlls and other library files to operate, or on any Linux distribution, where the files are spread out about the filesystem. In both these cases, the only humane way for the user to access their applications is through a shortcut file, which provides a confusing interface for users who may think that deleting the shortcut file is removing the program from their system altogether, which it is not.
Mac OS X bundles are of several different types and are very limited in their scope by what the Finder will recognise and do with them by default. My proposal is for a system similar to this for Haiku, but much more flexible. This would be easy to implement for applications as there is already a standard location in the file system which contains them. The proposed '.box' files would be customisable by users and developers to do whatever they wanted to.
Anatomy of a '.box' folder
A .box folder contains any combination of files and folders that may be needed to open it. However, it also contains the following files:
.bundle_info
This, in addition to the '.box' extension of the folder name, identifies a folder to the Tracker as a bundle. It contains the information needed for the bundle in an XML format. It includes information such as what to do when a bundle icon is clicked on, the icon of the bundle, a description of it, etc.
The reason the information inside .bundle_info is not stored in the BFS metadata system is to aid the transmission of files across the Internet. Folder compression formats such as .tar and .zip files do not preserve the filesystem metadata and therefore it is more useful in this case to put the information inside a hidden file.
an icon
An icon in the Haiku standard icon format. It may have any name is it is referenced inside the .bundle_info file. If the icon is not present, a default icon should be displayed.
something to do
This is optional as a bundle may (through the .bundle_info file) have been set to act as a shortcut to another location on the filesystem and may not actually contain any data.
Conclusion
Introducing a bundle format to Haiku would make its interface friendlier by allowing users to manage their applications much more easily. They would require only minimal input from application developers, who would only need to distribute their files as bundles instead of plain folders. The bundles are also backwards-compatible with the original BeOS, because all bundles can be opened as folders in the Tracker and allow the application inside to be opened in the usual way.
Not requiring the use of filesystem metadata negates the need for a special compression mechanism for the folders to be transmitted across the Internet—industry-standard formats can be used for this to avoid work on a platform-specific format.
