Hi, I've documented the classes (I've also changed some bits) and start now with the implementation. As already discussed, a big part of the logic will live in the registrar. It maintains an up to date device list, sends notification messages for the various events and handles requests from the user API. Those requests are: * `get next device': Used for iteration. The user API sends a cookie and the registrar returns a device and a new cookie value. * `get device/session/partition for ID': The registrar returns a device for a device/session/partition ID. * `update device': The user API requests an update for a device. To keep the server side simple, the registrar simply returns the complete info for the device, and the user API can interpret that info appropriately. * `register/unregister for notifications': ... (The protocols are defined in `docs/develop/servers/registrar/ Protocols'.) That's it basically. In fact the first three requests are even pretty similar. What is mainly needed is the functionality to stuff a device info into a BMessage and extract it from one. Since the GUI add-ons will be loaded from the user API, not from the registrar, the functionality can indeed be added to the real registrar, while for the time being the user API can't be added to libopenbeos, if we want to be able to test the GUI stuff. Some small hacks should make it possible for the user API to communicate with our registrar even when not linked against libopenbeos. I will start with the core of the registrar side implementation -- i.e. with classes to manage the data -- will then implement the basic functionality of the user API, add notification support afterwards, and finally get partitioning and FS initialization (the latter one as far as possible) done. CU, Ingo