On 03/10/2013 08:59 PM, Tyler Romeo wrote:
My main concern with the program in its current state is the lack of sufficient design. I mean, both the Configuration and MessageRouter objects are glorified dictionaries (or defaultdicts), and global variables are used for the router and config.
That's quite intentional. The intent was to make it as simple as possible.
Anyways, this thing is currently 200 lines of code, so refactoring it is really simple. I guess at some point every simple 200-line Python script has to turn into a beautiful, elegant 600-line Python script.
(or into a 50-line Haskell script where nobody really understands what's going on, but that's the other story)
Also, the config protocol is almost definitely a bad idea. Since it's unauthenticated, the only way to guarantee security is to use a Unix socket (or some other only-locally-accessible method), at which point you already have the means of stopping the server and reading the config. Finally, stats should be fine if publicly available. In other words, the only useful thing the control protocol could be used for is reloading the configuration.
Eh... it is a Unix socket. The only actual purpose I added it was to support configuration reloading, because doing that through SIGUSR1 would bring us to the signal minefield.
Other than that, minor quirks, such as handleJSONCommand, a protocol function, being put in the Subscriber class.
Well, there are two classes doing almost the same thing, but having incompatible interface due to being derived from different protocol classes. I wanted to fix it first, but that would involve multiple inheritance, so I decided just to offload the feature to Subscriber. Of course, I could have created another class called JSONSubscriber for that.
As usual, patches welcome.
And, of course, there's the issue of performance. Python doesn't handle threads, and since Twisted isn't multiprocess AFAIK, this might not be able to handle that many connections.
Well, the issue here is that you essentially have a simple program which takes message from one port and then resends it to many others. Even if threads would be of help here, Python works better with I/O-bound multithreading than with other sorts.
Finally, other than WebSocket and the socket interface, the one other subscription method we should have it some sort of HTTP hook call, i.e., it sends an HTTP request to the subscriber. This allows event-driven clients without having a socket constantly open.
I am not sure what exactly do you mean by that.
Thank you for your feedback.
-- Victor.