One hole that I feel like I'm seeing in the messenger interface concerns credit.
I have a way of using credit to set a max number of messages that a recv call should return in one gulp, or a way of doing ... something that I'm still figuring out ... by setting credit=-1. What I don't have is any way of getting guidance about what effect my credit allocation is having. A messenger app might have some flexibility in how much time it spends servicing incoming messages vs. time it spends doing its own processing, and it might be able to allocate more time to servicing incoming messages if it knows more about what's happening. Alternatively, it might want to set the credit allocated per recv call based on the number of current incoming links. ( And assume that the credit will be distributed round-robin across all incoming links. ) Would it be practical / desirable / catastrophic to expose current backlog or number of incoming links, or both, at the messenger level ? Or would that violate part of the messenger API philosophy? ( And if so, what is that philosophy? I want to be able to explain it. )
