[interfacekit] Re: Anyone working on BMessageQueue

>Thanks.  I have made good progress on BMessageQueue.  Check out the 
>following document, again comments welcome:
>
>http://www.Windswept-IV.ca/openbeos/BMessageQueueUseCases.html

Looks good.

>I am making good progress on the implementation and will start making a 

>test program which compares my implementation to Be's just as I did 
>with BLocker.
>
>Note, my investigation does reveal some comments being made on 
>bedevtalk to be true.  Be does seem to make use of friend classes quite 

>a bit internally.  In this case, BMessageQueue is a friend of BMessage 
>which allows the BMessageQueue to directly modify private members of 
>the BMessage class.  I will take the same approach since I think there 
>are good reasons for doing so.  The main reason I think is performance.

Yes, friendships run rampant in the BeAPI.  What we have discussed is 
building classes which abstract the friendship out -- essentially 
creating a private API that classes can use to get access to internals 
they need.  For instance, for BView there would be a BViewInternals 
class that other kit classes would use.  BViewInternals would not be 
part of the public API interface.  BViewInternals would be the only 
friend BView had and everybody else would use BViewInternals instead of 
being friends.

>On bedevtalk, people are discussing whether to recreate BeOS as is or 
>try to improve on some of its faults as the work progresses.  My 
>approach for now is to implement what I am seeing.  I will document any 

>critiques I have of the implementation as I go along and perhaps we 
>will revisit them in the future.  However, I am inclined to believe 
>that something like the friendship between BMessageQueue and BMessage 
>was done for a good reason and changind the implementation drastically 
>until we understand those reasons is foolish.

Yes, go with the straight implementation.  If there is some change that 
seems extremely cool/necessary just bring it up with the group.  
Improving on failure modes is certainly something you could do without a 
second thought.  For example, several of the archiving functions have 
segment violations if you pass NULL parameters, which simply doesn't fit 
into my notion of a well-behaved API, and you can be sure that my 
implementation does no such thing. ;)

>My main concern though is with the more complex classes.  I think this 
>friendship between complex classes like BMessage and BApplication etc 
>could make our job of figuring out how this stuff works pretty tricky.  

>Will we ever really understand some of the side affects of how a 
>particular BApplication member might modify BMessages?

Fortunately, we're in total control of what those side effects are. =)  
We should look carefully at each friendship and see if we can't 
accomplish what's necessary without it.  And do the private interface 
thing.

>My plan next is get some of this stuff checked into cvs (just got cvs 
>to sourceforge working last night) and then to work on BMessageFilter 
>or BInvoker.  If anyone is already running with BMessageFilter or 
>BInvoker, please let me know.

We have a BInvoker implementation that I will check in soon, courtesy 
the BlueOS guys.  Please hold off on checking in until I say "OK" -- 
there's still a bit of administrivia I want to get sorted out first.  
Shouldn't take more than this week to iron out.

>>>I am looking for another class to tackle.  Anyone already working on 
>>>BMessageQueue.  Please let me know ASAP because I plan to start it 
now.  
>>>Thanks.

You go to town. =)

>>Not AFAIK. BTW, after a quick scan of your BLocker docs, I'd say you 
hit 
>>things right on the money. :)

Yes, the docs looked pretty good to me as well.  In particular, I 
enjoyed your lengthy in-source discussion in AquireLock().  One thing I 
want to ask is that you use CppUnit for your testing framework; it will 
help us easily integrate all our tests into one all-encompassing suite 
-- which, given the total amount of work we're doing, is definitely a 
must-have.

e

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: