[interfacekit] Registrar: Milestone 1 reached

Howdy guys,

yesterday in the late afternoon -- some may call it today's early 
morning -- I committed the last tests for the currently implemented 
BRoster functionality, and by that finished phase 1 of the laid out 
registrar development road map.
In other words: Hooray, Milestone 1 has been reached! :-))

I'd like to summarize, what has been accomplished and where to find 
what code.

Implemented features:
1) BMessenger: Completely.
2) BRoster: Almost everything that has to do with running applications, 
i.e. the private methods for app registration (excl. SetSignature() and 
SetThread(), but I wouldn't know, why they were needed) and the public 
methods IsRunning(), TeamFor(), Get[Running]AppInfo(), GetAppList().
3) BApplication: The signature constructor, InitData() -- not 
completely: the connection to the app server is not initialized as well 
as a lot of members -- Run() and Quit(). The registration with the 
roster is complete, and hooks like ArgvReceived(), RefsReceived() 
(untested, needs BRoster::Launch()), ReadyToRun() are called properly.
4) Registrar: The registrar skeleton: An application class dispatching 
messages, an empty clipboard handler, an empty MIME database manager. 
The TRoster class, the actual roster, is almost complete.

Although BRoster::Launch() is not implemented, the support for it in 
BApplication and TRoster is already there, untested of course. App 
activation (BRoster::ActivateApp()) has an implementation, but it is 
provisional, since, as I wrote a while ago, we need the app server for 
this and some good ideas.

Let alone app activation this is indeed everything scheduled for Ms 1. 
The Plan (tm) looks still good to me.

Here's a short round trip through the code:

* BApplication, BMessenger and BRoster live in their respective files. 
That is not very surprising. Note, _send_to_roster_(), needed for 
BMimeType, BMessageRunner and BClipboard, is implemented and documented 
in Roster.cpp.

* docs/develop/servers/registrar/Protocols is a collection of the 
(currently used) protocols for the communication with the registrar, 
i.e. the message and reply message layout and meaning.

* headers/private/app/RegistrarDefs.h and src/kits/app/
RegistrarDefs.cpp define message, type, error and other constants 
concerning the registrar.

* headers/private/app/AppMisc.h and src/kits/app/AppMisc.cpp contain 
some private miscellaneous functionality I didn't know whereelse to 
put.

* src/kits/app/InitTerminateLibBe.cpp contains init_before() and 
terminate_after() which call the _init_xyz_() and _delete_xyz_() 
functions. Currently only for BRoster.

The registrar code lives in src/servers/registrar and consists of:

* Registrar.cpp/h: The registrar main() and the application class.

* ClipboardHandler.cpp/h: A BHandler derived class responsible for 
clipboard handling (empty implementation).

* MIMEManager.cpp/h: A BLooper derived class responsible for MIME 
database management (empty implementation).

* TRoster.cpp/h: The roster implementation.

* RosterAppInfo.cpp/h: A struct extending app_info by some more data 
needed by TRoster.

* AppInfoList.cpp/h: A RosterAppInfo list class.

* Debug.h: Contains some nice macros for debugging output. Stolen from 
Axel's BFS implementation and slightly adjusted. :-P

There is quite some testing code for BApplication, BMessenger and 
BRoster in the respective subdirs of src/tests/kits/app. In  
bapplication and bmessenger reside directories `testapps' which 
contains the code for test applications ran by the unit tests.

In src/tests/servers/registrar lives (besides RegistrarTest1.cpp, which 
is not really needed any more) the file RosterShell.cpp which compiles 
to a helpful debugging tool. It can list the currently registered 
applications and quit or activate any of them.

What now? Heading towards milestone 2, of course.
According to The Plan this includes the complete implementation of 
registrar side MIME support, BMimeType, BNodeInfo, BAppFileInfo and 
BRoster::FindApp(). We have a little head start, since Tyler and I have 
already implemented the BMimeType tests and Tyler has been working on 
the BMimeType implementation for... er... two weeks or so and has 
finished MIME sniffing basically. :-)

Currently the Storage Kit classes live in a separate library, 
libstorage.so, but in phase 2 we will need to integrate it into 
libopenbeos.so. This will have two consequences: 1) BApplication will 
use our BAppFileInfo which therefore needs to be implemented at that 
time, and 2) some of the SK Kit tests will break as they use App/
Interface Kit functionality that libopenbeos doesn't provide at this 
time. This does in particular concern some BMimeType tests using 
BBitmap. Therefore it might be necessary to provisionally implement 
BBitmap. I guess, we will just do it, when it comes to that.

Well, that's it so far. I'm going to tackle BAppFileInfo...

CU, Ingo

PS: Can someone please post a news item.

Other related posts: