today we released electroserver 4.06! from the release announcement:
You can now get through firewalls, opening your applications to the widest audience ever using the new HTTP connection option. If a client can’t successfully establish a socket connection with the server due to firewall security then HTTP connection can be used and it will just work. As a developer, the only difference in the way that you use the API is you will call createHttpConnection instead of createConnection. All other calls and events are identical!
the implementation wasn’t bad at all. due to the usage of mina on the backend, it was very simple to plug in alternate frontend that wraps our existing protocol. i hacked and back-ported pieces of the mina 2.x branch http client code for a very simple http implementation that wraps the electroserver binary protocol as the request/response payloads. it was really just an extra link in the chain before the existing logic that expected the binary protocol on the wire directly. add in some support for storing messages for clients and voila.
due to how mina itself works, comet / long poll support also “fell right out” of the implementation. this means that for message receipt, if there is an open channel, using http is just as performant as electroserver’s native binary protocol.
there was also another funny bug that i fixed that involved making a reentrantlock fair. this was the first time i had personally witnessed the needed to use this option, but when dealing with the need to process things in-order where messages can arrive via multiple threads, its a lifesaver.
I just read elharo’s IDEA criticisms, and since keyboard shortcuts are his main one, I thought I’d share the set I’ve been using for years in IDEA.
Like him, when I started using it on the Mac, they drove me nuts. Since this was back when Eclipse sucked mightily on the Mac, I remapped them all.
You can download the file here. Place it in your ~/Library/Preferences/IntelliJIDEAxx/keymaps folder and restart IDEA.
my job involves a lot of concurrency, since we specialize in infrastructure for multiplayer games.
i have a lot of ideas on how to simplify the programming model we expose to plugin developers, some of which i’ll be expanding upon at a later date.
it reminds me a lot of the old excalibur event code that the avalon team worked on years ago.. trading sinks and sources for publishers and subscribers, the end goal is the same. i tried to revive the event code a month ago or so, but it felt to large.. not all of the functionality was really needed.
jetlang does it right.. its simple and focused, and will be an excellent base to build upon.
mike posted about a 0.1.3 release today. i’m fairly happy with the api, and i think mike is too. next thing i want to tackle is a maven build, to help bring it to a wider audience. then, time to build stuff on top of it!