Goals

1. Clean code
   • Fewer bugs
   • Lower the barrier to contributing
   • Easier to maintain and track down problems
2. Portability
   • Written in C
   • No longer requires C++ compiler
   • No more writing C wrappers around C++ API
   • Easy to embed and hook up to other languages (Ruby, Python, etc)
3. Flexibility
   • Multiple reactors
   • Modular components – don’t need it, build without it
   • Plugins for extra native stuff?
4. Profitability
   • Duh.

Game Plan

EventMachine is currently a big glob of code that does a lot of stuff. We want to separate this out so that different pieces are reusable and easier to maintain as individual units, and the functionality that EM provides is more clearly defined.

EM is 3 things:

1. Event Framework
2. Non-blocking I/O library
3. Task scheduler

In this iteration of EM, we plan to clearly delineate (write as entirely separate units, probably) at least the first two.

1. An event loop with back-ends for all of the usual OS mechanisms (epoll, kqueue, poll, inotify, etc.): feed in a file descriptor or equivalent, and get your callback fired when something happens. This is also where timers will probably have to reside.

2. I/O handling. Hand off I/O work to this component to have it magically completed in a non-blocking fashion and let you know when it’s finished. This will be the core of networking utilities. Non-blocking creation/connection of sockets, asynchronous DNS resolution, and reading/writing sockets will all reside here. We can also write native support for things like file-to-socket I/O and socket proxying in this piece.

Why don’t you use libevent or libev?

• General opinions of these libraries seem to be poor
• Unfamiliar – overhead in learning APIs
• Do they support everything we need, the way we need it?
  • We could think so now, and find problems later
  • In which case we would be glued to a library we don’t have control over
• They are pretty old. Maybe we’ll put new spin on things.
• If you want libev, you can use cool.io.

Code

• Standard code style, to be determined
• Follow POLA/POLS – No tricky stuff. Any developer should be able to figure it out.
• Tests. TONS of tests, that make sense, for everything. EM is a very complex library, and we should test with as fine a granularity as possible. We should be able to identify the exact source of a problem quickly.

Early tasks

• Learn Autotools as it relates to us, and get a build environment configured. This should be documented so other people can see what is going on without spending a month learning Autotools.
• Decide on a testing methodology/framework. Here are a bunch
• Come up with a reasonable way to provide logging and statistics