Excerpt: The Filetyping Problem Guilt by Association The Filetyping Solution: MIME Meet the Registrar Assigning MIME Types: The Rules of Engagement If you've been poking around in BeOS's nooks and crannies, you've probably noticed two rather similar applications with almost identical names. One is called FileTypes (plural) and lives in your Preferences folder. The other is called FileType (singular) and is accessed as a Tracker add-on (right-click any file and select Add-Ons | FileType from the context menu). It's important to understand the difference between these two, and to learn to use them both. Mastering this pair can help you to better understand how BeOS works internally, and will simultaneously give you more latitude and control in your daily work. Before diving in, though, I'm going to branch off on a detour and take a look at the big picture so you know exactly why BeOS filetyping works the way it does, and what problems it's meant to solve. We'll return to the FileType panel after this brief message. Guilt by Association What happens when you double-click on a file in other operating systems,like MacOS or Windows? A file is launched in an application, sure. But how does the system know what application to launch? What criteria does it use? Are they good criteria, or are you stuck with a set of 15-year-old rules for defining preferred applications? Let's say you're in Microsoft Windows (any version) and you double-click a file called readme.txt. It pops up in Microsoft Notepad because Notepad is set up to be your preferred application for all files ending in .txt. Files ending in .doc open up in Microsoft Word, files ending in .psd open in Adobe Photoshop, and so on. If you want a file to open up in another application, you just rename it with a different extension. It's fast, easy, filesystem-independent, and ... stupid. Really, really brain-dead. For one thing, the three-letter extension is an inelegant requirement and makes your directory listings look as complicated as the NASDAQ. Second, it's a lot to ask of new users, who are having enough trouble finding their way around the system without having to memorize a huge list of extensions. But finally, and most profoundly, it's too easy to screw things up. If you rename a text file to readme.doc, no problem--Word can open up a text file just fine. But if, on the other hand, you rename a Word document with a .txt extension, Notepad is going to try and open it, and choke badly. Rename an Adobe Acrobat file with a .jpg extension, and your image viewer is going to get very confused. What's more, you now have no easy way of determining what the actual filetype is, aside from making educated guesses until you get it right. Tagging a few letters onto a filename only appears to change the type of the file because it changes the icon. In reality, the actual document type is untouched, and you end up with icons that lie to you, masquerading as something they're not. Granted, this scenario doesn't happen too often, and most people get used to using extensions early in their Windows careers and never think about it again. The nice thing is that you can change the preferred app for an entire directory of files just by typing something like ren *.txt *.html from a DOS prompt, which can come in pretty handy. The other nice thing about using extensions for filetype identification is that files coming from the Internet or other operating systems are handled quite easily as long as the extension is in place. Finally, and perhaps most importantly, Microsoft Windows users can make a single tweak and change the preferred application for every .txt file on their system, instantly. But woe be unto the poor user who finds herself with a file called J8tee7x with no extension and no clue whether it's supposed to be a text document or a bitmap image. On the other side of the fence is the Mac way of doing things. Under MacOS, every file stores extra data in the filesystem, containing information on things like the preferred application for that file. As a result, Mac users can call their files anything they like and the files will still open up correctly in the preferred application. In addition, their files can take any icon, giving them a higher degree of customizability. But there are big problems with the Mac way as well. For one thing, MacOS makes one big assumption: that the application that created a file is the one you'll prefer to view it in. As a result, if you make a JPEG file in Photoshop and then later double-click its icon, you're going to have sit around and file your nails while you wait for Photoshop to load just so you can view your image. Yes, you can change the preferred application so that this particular file launches in a snappy little app like JPEGview, but there's no way to do it for all of your JPEGs system-wide. Third-party utilities help some, but this really shouldn't be the domain of third parties. Even worse is the inconsistency. Let's say you have a folder containing 100 HTML files. Some of them were created in SimpleText, some were saved down from the Web via Netscape, some were made by a co-worker using BBEdit, and a few were written in Microsoft Word. All of the files are pure HTML, but MacOS displays them with four different icons and opens them with four different applications. Again--brain-dead. But one of the most problematic things about filetyping on the Apple Macintosh is the fact that it only works as long as you're exchanging files with other Mac users. Because Mac users aren't in the habit of using extensions on their filenames, and because the extra filesystem data isn't understood by or transferred to other operating systems, Mac files just get blank, generic icons when copied to a Windows system. And try teaching a MacOS newbie learning to build his first Web site why it's important that he end all of his documents with ".html". The Internet (which runs mostly on Unix) uses extensions for file identification too. Both of these systems have their strengths and weaknesses. The Windows way is fast and efficient as long as everyone follows the rules. But the rules really suck, allowing for mismatched filetypes. The Mac way is more elegant for the newbie, but it makes terrible assumptions about which application should be the preferred one. It also has serious limitations for the power user, who can't change the association for a given filetype system-wide. Third-party utilities help in this domain, but this really should be considered the province of the operating system itself. There's got to be a better way. Which brings us to BeOS. The Filetyping Solution: MIME When MacOS and Windows were developed, hardly anyone knew the Internet even existed. But BeOS had the advantage of evolving while the Internet was in heavy growth mode, and Be was paying attention. One of the Internet's great strengths is the fact that it's inherently cross-platform. Theoretically, documents made on any operating system can be viewed on any other operating system. While that may seem obvious and old-hat to you by now, this was pretty exciting stuff to geeks the world over once upon a time. In fact, it's one of the many reasons for the Web's rapid rise to mass popularity. And how did the Web break the cross-platform boundary? By adopting an intelligent, platform-neutral system for identifying filetypes. Rather than worrying too much about how to handle proprietary file formats like Word and Photoshop documents, the Internet depends on a system called MIME, or Multipurpose Internet Mail Extensions (the "mail" bit arises from the fact that MIME grew out of solutions originally built for handling email attachments). The MIME system looks at filetypes in terms of their overall class (image, text, audio, and so forth). Every file, without exception, belongs to one of these meta-classes, or "supertypes." Then the exact type of file within that class is specified. For instance, images can be JPEGs or bitmaps, text files can be plain text or HTML, and so on. There are hundreds of MIME types registered by an international standards organization called the Internet Assigned Numbers Authority (IANA, www.iana.org), and developers of new file formats are free to register them in this central MIME database. Filetypes are thus assigned in "supertype/type pairs" with the following format:   Figure 5.20 You may be familiar with the Internet's MIME schema if you've ever poked around in Netscape Navigator's MIME database, which lets you establish preferred applications for files accessed online. BeOS takes the same MIME concept and extends it to the entire operating system. CLASS/TYPE image/jpeg text/html audio/wav application/exe and so on. Whenever a file is transferred from a Web server to your browser, its MIME type is sent along with it. Neither the server nor the Web page dictates which application should handle any given MIME type--that's up to the recipient's browser or operating system, and is configurable by the end-user. Thus, say your copy of Netscape is configured to launch the RealAudio player whenever it receives a file with the MIME type of audio/x-realaudio, and to display documents of type text/html within its own window. If you'd rather have your favorite audio application play downloaded .wav files rather than your browser's built-in player, all you have to do is tweak the MIME type in your browser preferences. In this way, the MIME system serves as a sort of abstraction layer, doling out just enough information about a file's type to get the job done, but leaving plenty of room for every user to configure their preferred application for each filetype. What happens when the server doesn't send a MIME type along with a file? That's when Plan B kicks in. The browser examines the file's extension and runs a lookup in its database of known types. If your browser already knows that files ending in .wav are almost always of the type audio/wav, then it can still figure out which application gets to handle the file in question. The system is fast, logical, inherently compatible with any operating system, and, thanks to its simplicity, reliable. By now you're probably wondering what all of this has to do with BeOS (or maybe it's obvious by now). Rather than repeat the sins of systems past, Be took the well-established MIME system and fused it into their operating system. All application associations in BeOS are handled by MIME types--the same kind of type/creator pairs used on the Internet. Be's adoption of the MIME standard is a fine example of the company responding to the wishes of the developer community. Chris Herborth, this book's technical editor, spearheaded a movement to get the original Mac-style type/creator system replaced by the superior MIME scheme. Of course, the MIME standard was never designed to support an entire operating system, so Be has added a lot of extra functionality and intelligence to the basic idea, adapting the concept to suit their needs. For instance, the MIME system already handles classes and types of documents very nicely. But what about the program files themselves? In BeOS, most of your applications have both a standard MIME type (application/x-vnd.Be-elfexecutable for x86 or application/x-be-executable for PPC), as well as a unique "signature" that looks much like a MIME type, but is not. Table 5.02 Signatures of some common applications Application Signature StyledEdit application/x-vnd.Be-STEE Tracker application/x-vnd.Be-TRAK CDPlayer application/x-vnd.Be-CDP! Pulse application/x-vnd.Be-PULS BeMail application/x-vnd.Be-MAIL For the sake of illustration, we'll use the CDPlayer application that comes with your system. Its MIME type (on R4/x86) is application/x-vnd.Be-elfexecutable, while its signature is application/x-vnd.Be-CDP! (I'll show you how to discover these later), and this is the only application on your system with this signature. As you can see, the format of the signature is similar to the MIME-typing convention, but you should not confuse application signatures with MIME types, which are functionally different. Because every application has a unique signature, the system can communicate with it (or launch it) without having to know where on the user's hard drive the program lives. This lets you do things like launch applications from scripts without having to know where on the system the application is located. The somewhat confusing distinction between MIME types and signatures will probably never affect your daily work, as it applies only to applications, not to your data files. Remember: All files have a MIME type, but only applications have a signature as well. Not every executable application on your system has a unique signature. For many smaller applications, especially command-line-only apps, there's just no reason to establish a signature. For example, the small binaries that live in /boot/beos/bin/ all share the same MIME type--application/x-vnd.Be-elfexecutable (on R4/x86) but none of them has signatures. While this is not universally true, in general you can expect that GUI applications will have signatures, while command-line programs will not. The "vnd" in the signature, by the way, is short for "vendor." Commercial BeOS application vendors will include some part of their company name, whereas these signatures say "Be" since that's who provided them. The Format of a MIME Type When a developer is creating a new application or filetype, she has to assign it a MIME type. But she can't just make it up from scratch--BeOS respects international MIME type standards, along with all of their formatting rules. The MIME type must consist of printable, seven-bit ASCII characters, and must not use any of the following reserved characters: /<> @,;:\"()[]? BeOS limits MIME type lengths to 240 characters, but does not enforce any other rules on top of these. Since the list of valid types is dynamic, Be can't be in the position of policing every new type that gets created--it's up to the developer to use proper types. However, illegal MIME types will generally be brought to the developer's attention by the mysterious "MIME Police" (a pseudonym for a loose band of techno-terrorists dedicated to stamping out evil, invalid MIME types). Even though BeOS itself does not enforce additional rules for MIME types, it's a good idea to get in the habit of following the international MIME standards if you intend to create your own filetypes. If you create a new type for your personal use or for use by your own application, you should precede the type with x- to indicate that this type has not yet been accepted into the official, published database of known MIME types. For example, if you want to create a new type of text document for your own use, you'll want to give it a type something like text/x-funky, not text/funky. Nothing in BeOS will prevent you from doing anything you like, but you probably don't want to risk a visit from the MIME police. Revenge! Want to find out if there are any invalid MIME types lurking on your system? Download Rainer Reidl's Revenge of the Mutant MIME Types from BeWare--it'll scour your volumes for nefarious, naughty MIME types and give you the option to automatically correct them. For more information on the MIME standard, see http://www.qnx.com/~chrish/Be/info/mime-references.html. Meet the Registrar A brand-new, fresh BeOS installation already registers more than a hundred MIME types. As time goes on and you install more software that creates more types of files, that list will grow. If you guessed that someone--or something--must be keeping track of all these MIME types, you win a cigar. Just as your browser keeps a running database of known MIME types as you surf, BeOS also has a central MIME registry, and it's administered by something called the Registrar. You'll never see the Registrar onscreen, but it's chugging away tirelessly in the background, making sure your files are launched into the right applications, remembering which signatures belong to what, and checking to see that all of your files have associated MIME types. You don't have to do anything special to put the Registrar to work; each time you launch an application, the Registrar checks the program's signature to see whether it's already in the database. If it isn't, it gets added. If it is but the user has moved the program, the entry is updated. The Registrar then announces to the rest of the system that the app is running so that scripts and other programs can interact with it by its signature. So how does all of this work again? You double-click an icon and the Registrar takes a look at the file's MIME type. If the file has the MIME type of an application, the app is launched. If it has another MIME type, the Registrar looks in the FileTypes database to learn the preferred application for handling files of that type and launches your document in that application. If the file you selected doesn't have a signature, as would be the case with files arriving via floppy (a.k.a. "sneakernet") from another operating system, or in some cases with files downloaded from the Internet, the system has a backup plan. Each filetype is allowed to have extensions associated with it in the FileTypes database, so that if the MIME signature is missing, BeOS can do its best to assign it one. For instance, if you get a floppy full of HTML files from a Windows friend, the Tracker will display them with generic icons, since it can't find a MIME type in their attributes. But if FileTypes has been told that files ending with an .htm or .html extension are almost certainly HTML files, the Tracker will associate the files with the application specified under text/html in FileTypes (which is most likely NetPositive). From where you sit, though, it's all very simple. You double-click on an icon, and BeOS does the right thing. Thanks to the MIME system and the tireless efforts of the Registrar, BeOS effectively solves the filetyping problem that plagues most operating systems. With BeOS, you get the best of all worlds: No arbitrary restrictions on filenames. System-wide control over preferred applications for given filetypes. Localized control so that you can change the preferred app or icon for a single file or an entire directory of files (although you'll need to use the Terminal to change types for all files in a directory, or use a tool like DropType, which is discussed in Chapter 10, System Tools and Utilities). Control over the list of filetypes that an application handles by default. In the next section you'll learn how to change the preferred application for a given filetype, alter or repair MIME types when necessary, and make changes to the list of filetypes that an application can handle. Assigning MIME Types: The Rules of Engagement There are two major points at which BeOS must address how to handle your files: deciding what to do when you double-click a file's icon, and assigning MIME types when none are present. Each of these tasks involves stepping through a series of conditionals: if/then statements that lead to the right thing taking place.   Figure 5.21 When BeOS runs out of tricks to determine a suitable application to launch a file in, this dialog is displayed. Clicking the Find button launches the Open With panel, shown in Figure 5.22. Deciding What to Do when an Icon Is Clicked When you double-click an icon, the Tracker and the Registrar work together to determine the proper course of action. They go through the following steps, which sound simpler than they actually are: The Registrar looks for a MIME type in the file's attributes. If none is found, branch to "Assigning a MIME Type," below. If the MIME type is that of an application, launch the application. If this file has its own preferred application, launch this file into that application. If not, then look up this MIME type in the FileTypes database. Does this MIME type have a preferred application? If so, launch this file in that application. If not, does this MIME supertype (that is, "text") have a preferred application? If so, launch this file in that application. If not, announce to the user that no suitable application could be found (Figure 5.21). Figure 5.22 Clicking Find will display the Tracker's last resort: the Open With panel, which displays all of the applications on your system registered to handle all types of files (these applications are also known as "superhandlers"). While there are quite a few choices pictured here, in reality most of these applications won't do you much good. Ninety-nine percent of the time you'll want to choose the FileTypes panel, which you can use to manually specify an appropriate filetype. Assigning a MIME Type Where There Is None When a new file arrives on your system without a MIME type (as happens when bringing files over to BeOS from other operating systems), the Tracker and the Registrar work together to assign it one. The Registrar's first recourse is to look for an extension on the end of the filename, like .jpg, .txt, or .html. If it finds one, it checks the FileTypes database to see whether you've connected that extension with any particular filetype. For example, you may have used the Extensions section of FileTypes to declare that files ending in .html were likely to be HTML documents, and that they should inherit the text/html filetype. If no extension is found, the Tracker will actually read a small portion of the file with a "sniffer." If it encounters plain text, it will assume that this is a text document and give it the appropriate MIME type. A similar process occurs with GIFs, WAVs, and other common filetypes. Because the extensions technique is more likely to be accurate, it's run first. Assuming you've set up a few common extensions in your FileTypes database, BeOS can guess a file's type accurately the vast majority of the time, with the vast majority of files. To put this process to the test, try this: Make sure you've added the .html extension to your text/html filetype in the FileTypes database. Close it and find a plain text document on your system. If its name has an extension, rename it so it doesn't. Open a Terminal and use the rmattr commands described in the previous section to remove the attributes BEOS:TYPE and BEOS:PREF_APP (if there is one). Back in the Tracker, your file should have the blue generic icon. Double-click it, and it comes right up in StyledEdit. Remove its attributes once more, then rename it with an html extension. Double-click it, and it comes up in NetPositive. From this you can see that a filename extension is respected first if one is present. In its absence, the file data itself is sniffed. If all of this sounds like a lot of work, remember that the whole process is transparent to the user. In addition, the vast majority of the time a valid MIME type is found immediately and BeOS doesn't have to complete more than a couple of these steps. Even when it does go through them all, however, there's no perceptible performance hit. In exchange, you get maximum flexibility and intelligence from the design and construction of this system. The Rules of Inheritance On occasion, you may end up with files on your system with MIME types that are only partially understood, or partially present. For instance, let's say you created your own filetype with a MIME type of text/x-funky. It will work fine on our system because you're installing it in your own FileTypes database. But what would happen if you zipped up an archive including some of those files and sent it to another BeOS user? Amazingly, they would open up just fine on his system. His Registrar would encounter the MIME type text/x-funky and say, "Well, I don't know from funky, but I know text," and would promptly send the file to the app associated with the text supertype. Because x-funky is a child of the parent group text, it inherits text's properties if it can't find anything more specific to go on. As in any object-oriented system, BeOS always starts with the most specific rules, only resorting to more general rules when specific ones fail. Remember the discussion about icon inheritance earlier in this chapter? The exact same kind of specific-to-general rule ordering is taking place there. This system of object-oriented inheritance pervades BeOS, from the lowest levels of its programming API to its highest levels of interface design.