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

Reply via email to