[interfacekit] Library Initialization and Further Proceeding

Hi,

those of you that follow the CVS mailing list might have noticed, that 
I committed some registrar concerning stuff. Actually this is basically 
the complete implementation that had to be done for package 2. While 
coding I encountered a problem, or rather a now not longer unanswered 
question. ;-)

Most of you certainly have already stumbled across one or more of those 
_init_*_() functions in the original Be headers; _init_message_() and 
_init_roster_() to name two of them. Originally I believed, that they 
are simply called when a certain part of the API is "activated" the 
first time. E.g. I thought, _init_roster_() would be called by the 
application constructor. This is wrong. be_roster is already 
initialized when main() is called.

When I came to the point where I had to initialize be_roster, I was 
wondering how to ensure, that BMessage had already initialized its 
reply ports at the time when the BRoster constructor was called. As 
BRoster currently works, this is needed, since it synchronously asks 
the registrar for the MIME messenger -- Be hasn't done it this way, but 
anyway...

The answer is relative simple and is called initialize_before(). This 
function, if present, is called before the library's _init(), i.e. 
before global variables' constructors are invoked. In libbe this 
function calls _init_roster_(), init_message_() and _init_tokens_(). 
That way the initialization order can be defined -- exactly what is 
needed. :-) I also found a function terminate_after(), whose libbe 
incarnation calls a couple of _delete_*_() functions.

Tomorrow I will add the initialize_before() and terminate_after() to 
libopenbeos, adjust a bit of concerned code and start with package 3, 
i.e. app registration. Yes, this is not completely laid out. I 
originally planned to do that today and give you a chance to reply. 
However, I will investigate and rethink the matter, post my thoughts 
and, unless I hit serious problems, implement it immediately 
thereafter.

Tyler is done with the unit tests migration (Thanks!) and will, due to 
the single threadedness of the work left for milestone 1, start delving 
into the milestone 2 work, which is basically Storage Kit related (MIME 
handling, BMimeType, BNodeInfo, BAppFileInfo). Tyler, in case you will 
have to wait for anything I'm implementing, there are still the test 
suites for BNodeInfo and BAppFileInfo left to be written, and the MIME 
string functionality of BMimeType as well as 
BMimeType::CheckSnifferRule() don't need the registrar either...

CU, Ingo

Other related posts: