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.