With our team, we also found shared folders performance to be too low. Our Python framework/app is very read-heavy and stat() a lot of files (the Python module loading system isn't your friend)

We ended up using the synchronization feature in PyCharm to continually rsync files from native FS into the VirtualBox instance. Huge perf improvement but a little more cumbersome for the developers. But so far it has been working good, PyCharm's sync feature does what it is supposed to.

There's also Locust, a Python powered load testing tool similar to this. It's focused on simulating user behavior rather than hitting specific URLs. This allows for much more true-to-life testing.

We used it to load test Battlelog (the online service for Battlefield 3) and successfully simulated over 2 million concurrent users hitting the service using EC2. See http://locust.io for more info. (Disclaimer: I'm one of the authors)

Totally agree about having smaller and more contained apps.

I used https://github.com/cgbystrom/jersey-netty for a one-off project wiring Jersey together with Netty. But it's not async :)

Without need to discuss security implementations - no.

Protocol handlers are a pretty shitty way of interfacing with desktop apps. There's no two-way communication and no error handling. Lots of potential screw-ups and incompatibility issues will/can happen. Sure, they don't require a browser plugin but that's about the only advantage.

I would strongly advise not to base your push mechanism solely on Web Sockets. Despite advances modern browsers are making with Web Sockets support, the current compatibility is not there yet.

For starters, IE has no support, though that is starting to change with IE10. But the biggest issue is with personal firewalls / corporate proxies. These are unfortunately quite horrible at handling Web Sockets. Many popular firewalls such as avast! and Bitdefender can’t handle the WS protocol and completely blocks traffic despite browser support and it being valid HTTP. The socket.io guys did some extensive research on what firewalls are causing these issues. I don’t think their list is exhaustive but it features most major personal firewalls out there. Have a look at https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-f... , it's no reading of joy.

I’ve deployed quite large installations of Beaconpush (a push server incidentally based on Netty as well). First going from Web Sockets with fallback, over to pure WS and we’re looking at going back to using fallbacks once again due to these incompatibility issues. This time we are looking at using SockJS instead of rolling our own (to be fair, there were no open-source libs doing this when we started). I’ve ported SockJS to Netty (https://github.com/cgbystrom/sockjs-netty) and it’s working although I wouldn’t say it is production ready.

I urge you to have a look at SockJS and socket.io. Personally I prefer SockJS since it aims at emulating the Web Socket interface and nothing more as compared to socket.io (which adds a pub/sub layer). Also, it does not rely on a Flash fallback (which is another story). The socket.io guys are however working on engine.io, which will split the transport fallback mechanisms of socket.io to a separate library. That's a good idea, but it still uses Flash and IMHO a more complex "transport upgrade".

Redis should get an an HTTP API. Would enable you to implement something like this purely in the browser. UIs are really useful from a sys admin point of view. I can also imagine adoption increasing if Redis supported a UI out-of-the-box.

Redis does have an HTTP API, called Webdis. It takes the form of a server that sits in front of Redis, which may be not quite what you were talking about, but I find to be a very clean design. It's fast and full-featured, and is as easy to install as Redis itself. Just get the code, run make, and start the daemon. Maybe add a config file if you want to get really fancy.

http://webd.is/

I've been happy running it in production.

Now this is really interesting. I can think of about a dozen use cases off the top of my head.

This would be really nice. I tried (unsuccessfully) to get this running locally on OS X. The amount of dependencies required seemed very long.

The authors of Kotlin has explicitly said that fast compilation is a key feature.

It's also one of the key features of Turbo Pascal.

Planet Framework is designed from the ground up to be real-time and scalable, but it also uses a lot of existing open-source projects.

For Planet Framework customers, we offer "partner source". Meaning, that customers will get full access to source code and also submit their own patches.

Are you also going to open-source some parts of the project?

A couple of the components used are actually already open-source:

https://github.com/esnme/ultrajson - Super-fast JSON serializer.

https://github.com/esnme/locust - Scalable load testing tool capable of simulating millions of users.

https://github.com/esnme/amysql - 100% async/event driven MySQL driver.

https://github.com/hjlarsson/gevent-memcache - memcached driver for gevent.

Thanks for this list.

We've been building our own load testing tools on python, and it will be quite helpful to learn from the implementation of locust.

The reason behind "yet another template language" is that we compile down to both Python and JavaScript. Allowing us to render templates both on the server-side and client-side. Sharing templates between these two gets very important when you develop real-time web sites.

(I'm one of the developers behind Planet Framework)

Ah. That makes sense. Both Jinja2 and Mako are very much tied to Python. (Though compiling a subset of Jinja2 AST's to JavaScript would be an interesting exercise...)