But some people for some reason think, that an evented programming is actually the advantage of asynchronous I/O - probably because they have never used both models.
Yeah it's basically an unworkable model as soon as you have a client/server working through a conceptual set of shared/synced state. You end up having to break up a conceptually simple control flow into a messy explicit state machine on both ends... ick :)
Did you dig in far enough to explicitly enable the win32 back end or did you use the VisualD project? I'm asking because if the server is supposed to be command line only, the default libevent back end should work fine on Windows (for the VisualD project this would require removing the VibeWin32Driver version in the Compiler/General section).
VisualD project basically. I was originally just adding the relevant D files to my app directly (since I only really need to use it in "client" mode for now and want to keep the build simple for the time being) but ultimately I just added the VisualD project to my solution (and included a missing file or two) and then just linked the library and include vibe.vibe. Seems to be working fine other than the assert(false)'s that I hit when calling listenTcp, etc.
The win32 back end is currently developed in parallel to a larger project that needs it because it offers Windows event loop integration and a directory watcher. This is why it currently only has the features needed by that project. However, I wanted to get it completed for the next release (it would still be "beta" in that case regarding possible bugs and high-throughput performance). So if everything goes as desired, that would mean around the end of this month.
Great! Yeah it's actually pretty easy for me to "port" back and forth between my version and Vibe so when it's ready I'll happily drop the 3 or 4 files from my project that Vibe renders redundant :) Looking forward to using Vibe's much more polished HTTP/JSON setup vs. Phobos' minimal CURL/JSON stuff.