On 2003-08-26 at 15:50:39 [+0200], Ingo Weinhold wrote:
> On 2003-08-26 at 06:33:43 [+0200], Erik Jaesler wrote:
>
> > I did some work on BMessage over the weekend, and I think the public
> > interface is now fully implemented, though it's far from fully tested.
> > I'm just now writing a test app to do messaging for the first time. =)
> > Which brings me to a question. I start obos_registrar, then I start my
> > app, which causes obos_registrar to print "REG:
> > B_REG_GET_MIME_MESSENGER" to stdout, then nothing happens. Both my app
> > and obos_registrar just sit there. I've noticed this is also the case
> > with the various BApplication unit tests. Does anybody know which end
> > the problem is on, BApplication or obos_registrar? Maybe I'll just jury
> > rig something with a thread and a semaphore ...
>
> I experienced the same a while ago. IIRC, the cause at that time was, that
> you added the BMessage code to the build, but the BMessage::SendReply()
> methods had only empty implementations, while the private message sending
> methods BMessenger uses were implemented at all, so that the working R5
> methods were used. Hence the application successfully sent the request to
> the registrar waiting for a synchronous reply, which would never come since
> the registrar used SendReply().
> So, my suspicion is, that SendReply() doesn't work correctly yet. But I'll
> look into that.
I was more or less right. The reply wouldn't be delivered, for the
unflattened original message didn't contain the reply target info. The
reason for this was, that send_message() created a BMessenger with a dummy
handler token -1 (== B_NULL_TOKEN), which is considered invalid by
flatten_hdr(). I allowed myself to make that B_PREFERRED_TOKEN and now at
least the reply is delivered successfully. I tested with RosterShell, but it
doesn't behave right yet, I think. I'll have a closer look.
CU, Ingo
