Comment #2 on issue 2879 by matthew....@kitware.com: support for event streams
http://code.google.com/p/reviewboard/issues/detail?id=2879

If you look at the gerrit link, the way gerrit does this (which has value in a: makes it easier to port from gerrit to RB, and b: allows for much more loosely coupled, not to mention cross-server, interaction) is you ssh into the RB server and run a command that starts listening to the event stream. One important characteristic is that this works not only cross-process, but cross-*user*.

Do django signals do that? My naïve assumption was that they are in-process only (maybe I am wrong)? Ergo, some mechanism is needed to 'forward' the django signals to some IPC system. Since dbus is often running on modern linux systems anyway, and there is a good chance python dbus bindings are already installed also, my thought was to use that, but any IPC system could be used. Using the dbus system bus allows the (dbus) signals to be read by any process on the system (running as any user*), which allows for the 'ssh in and run the listener', similar to gerrit.

(* more fine-grained access control can be provided by modifying the dbus ACL's, e.g. to limit to only certain users.)

There could also be value using a network-based IPC system that wouldn't require being logged in, but then you're much more likely talking about something that isn't already installed, and needs to be installed on the client also. That's not to say that the benefits may not outweigh the drawbacks, just why my first thought went to dbus.

So... short answer to your question: no, dbus doesn't replace djang. Django signals the extension (in-process), which forwards across dbus (inter-process) to listeners (which are separate processes, which are almost certainly running as different users, since you don't want people logging in as the httpd user). I suppose you *could* replace django with dbus, but I doubt you'd want to; using IPC for intra-process communication is usually overkill.

--
You received this message because you are subscribed to the Google Groups 
"reviewboard-issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard-issues+unsubscr...@googlegroups.com.
To post to this group, send email to reviewboard-issues@googlegroups.com.
Visit this group at http://groups.google.com/group/reviewboard-issues?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to