Standard Event Driven Object Library for D

[Brian White]

> I'm also interested in the subject, though I haven't had a chance to 
> work on it. (I'm trying to get a full agile setup in D; I've done mock 
> objects, an xUnit, and dependency injection system so far. Events are on 
> my list, but not yet accomplished.) What sort of API would you want?

The event interface you describe is similar (the same?) as the signals 
module included, but that's not what I'm thinking about.  Instead, I'm 
leaning towards something like:

interface PathHandlerInterface
{
     bool PathReadHandler(int path);
     bool PathWriteHandler(int path);
}

...and...

interface SocketHandlerInterface
{
     bool SocketSendHandler(Socket s);
     bool SocketRecvHandler(Socket s);
     bool SocketConnectedHandler(Socket s);
     bool SocketBrokenHandler(Socket s):
     bool SocketClosedHandler(Socket s);
}

...and...

interface StreamHandlerInterface
{
     bool StreamReadHandler(stream s);
     bool StreamWriteHandler(stream s);
     bool StreamOpenedHandler(stream s);
     bool StreamClosedHandler(stream s);
}

interface SocketStreamHandlerInterface : StreamHandlerInterface
{
     bool StreamBrokenHandler(stream s);
}

...and...

class HttpServer : SocketStreamHandlerInterface
{
     ...
}


The idea, then, is that (for example) an HTTPserver object would derive 
from SocketStreamHandlerInterface for handing events.  The SocketStream 
class would have a pointer to an attached class and, if non-null, would 
call those methods off of it whenever it detected the stated condition. 
    That detection would generally be done in Socket*Handler 
implementations which were called by the attached Socket class.  It, in 
turn, probably called that function from within a Stream*Handler method 
called by the base Thread object managing the events.

As an example...

- An EvThread instance does a select and eventually gets a read event on 
path #N.  It does some work and then calls handler.PathReadHandler(pathno).

- The EvSocket object that was called as a result does some processing 
and eventually calls handler.SocketReadHandler(this).

- The EvSocketStream object that was called as a result does some 
processing and eventually calls handler.SocketStreamReadHandler(this);

- The EvHttpServer object that was called as a result reads the pending 
data, does its magic, writes a result, and returns "true" to say it 
handled the event and wants more of them.

- The EvSocketStream object thinks all is good in the world and also 
returns "true".

- The EvSocket object thinks all is good in the world and also returns 
"true".

- The EvThread object things all is good in the world and starts another 
select loop.

Had the event not been handled (returned "false"), it would have 
disabled read events on that path and continued on.

-- Brian