[bind10-dev] Messaging API questions

[Shane Kerr]

Michael,

On Thu, 2009-08-13 at 12:59 -0500, Michael Graff wrote:
> If a server is doing nothing but waiting for messages (such as a
> statistics gathering or logger module) then there is little issue; they
> will just block waiting for a message.  However, I suspect most
> consumers will want to do other things as well, like serve DNS data.

Crazy! :)

> The two usage models I can come up with here are pretty standard ones:
> the messaging API returns a descriptor that can be added to the usual
> event processing loop (libev in our case) and when I/O is available, a
> call into the messaging API is made to handle it.  This is all pretty
> standard and understood.
> 
> Now, my concern is what happens next?  Should the message API return and
> say "here's your message" or should there be a message callback?  I am
> generally fond of callbacks, but that was in C.  Is there a better way
> in C++?  Does the language matter?  Will a callback complicate Python or
> Ruby consumers of this API?  Or even C++ ones?


Diversion into Python:

Python doesn't have "interfaces" in the same way that Java does.
However, since it is weakly-typed it has the equivalent: classes have to
implement a specific set of methods (and possibly attributes) to be
used.

So, for example, if you want to use an object in a select(), you just
have to insure it provides a fileno() method, you don't have to be
descended from any particular class.

Having said that, most modules that have callbacks define a base class
that you can use if you want. The asyncore module is an example:

http://docs.python.org/library/asyncore.html

Things wanting events inherit from the asyncore.dispatcher class. They
can then override any methods they want.


> Not using a callback means that the thing doing the I/O needs to
> implement the same functionality, which seems simple enough.  But
> callbacks might be easier to implement and not require each application
> to "roll its own processing loop" as much.

The problem with callbacks is that if you want to roll your own
processing loop you can't. If we proceed down this road, we should
probably provide a way to invoke the processing loop with certain
restrictions.

For example, the asyncore.loop() method in Python looks like this:

asyncore.loop([timeout[, use_poll[, map[, count]]]])

The important bits are "timeout" - which gives a timeout in seconds, and
"count" - which gives a maximum number of iterations through the loop.
This means that applications that need or want to mix with other
processing loops can do so.


Maybe the important thing for the messaging API is that it be able to
work nicely with a processing loop. Perhaps we should define a generic
processing loop as a separate component?

--
Shane