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. )