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.

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to