Registrar Tasks:

- MIME Database chores (note that BMimeType appears to read from the database directly for `Get*()` calls.)
  - Writes to the database -- `SetLongDescription(), SetPreferredApp(), create_app_meta_mime(), etc`
  - Monitoring of the database -- `{Start,Stop}Watching()`
  - Sniffer duties -- Sniffer code plus `{Get,Set,Check}SnifferRule()`
- Timing chores
  - BMessageRunner functionality
- System Shutdown chores
  - Shutdown cycle
  - System shutdown window
- Roster chores
  - Recent documents, folders, and apps
  - Info about running applications
  - etc...

Registrar Internals:
The registrar is a non-standard `BApplication`. It has a shadow app in the `app_server` like a normal `BApplication`, but one of its ports is slightly different:

- Standard ports -- snd, rcv, AppLooperPort
- Registrar ports -- snd, rcv, _roster_port_

Since `BLooper::port_id` is private to `BLooper` (to whom `BApplication` is a friend), and since you can't rename a port after it's been created, it's likely that the only way to rename the `AppLooperPort` and have the registrar still be a `BApplication` is to have `BApplication` check if it's the registrar when it's created, and use `_roster_port_` as the name for what would otherwise be its `AppLooperPort`.
The rationale behind having a port with a specific name is that the registrar implements the roster functionality. Thus one can't address it using the app signature constructor of BMessenger, but rather must send the message directly to a named port (for example, upon creation, a BApplication object must find and contact the registrar to notify it of another running application; if the registrar cannot be found, the application putzes out).
The Registrar has three threads:

- _roster_thread_
- timer_thread
- main_mime

BMimeType Notes:

- The `Get*()` methods directly access the MIME database.
- The `Set*()` methods send a message to another entity which does the job. The function that does the sending is called `_send_to_roster_()`, so I suppose the roster is the one. Since the registrar has a thread named `_roster_thread_`, I assume the roster lives in the registrar.
- `Start/StopWatching()` call `BRoster::_Start/_StopWatching()`.
- Adding/removing a MIME type file in `~/config/settings/beos_mime/*/` does not trigger a notification message. So obviously no node monitoring is done and changes to the database are supposed to be done using the API.

Links:

- Icon World -- The Registrar
- The BeOS Bible -- File Typing and The Registrar
- BApplication
- BMimeType
- BMimeType (sniffer docs)
- BRoster