If you check my test case, you may notice that it looks different in Internet Explorer than it does in sane browsers. What is the culprit?

Simple: filter:alpha.

Supposedly, making elements somewhat transparent is possible in everyone’s favorite browser. Well, it is, but you have to use Microsoft’s proprietary “filter” CSS property.

Okay, fine, at least it works. Except in one case, from what I can tell: it will not apply transparency to absolutely positioned child elements of the element with the “filter” property set.

Why is this an issue? Let’s take the simple example of a button control (specifically, SproutCore’s SC.Button, but it should apply to other button controls as well): you have a left part (with nice rounded corners), a center part (that can be stretched), and a right part (again with the rounded corners). One part—for instance, the right part—is either positioned relatively or is the parent element itself, and simply has a background-position:right. The left and center parts, however, are positioned absolutely; something like left: 10; right: 10 for the center part; right:0; width:10; for the right part (I just made these numbers up! They aren’t real!)

So, what happens if you try to fade the button out in Internet Explorer? Well, it looks really odd. In the above example, the right part fades out, but the left and center do not. They just stay as they were.

There is only one workaround that I know of: seting filter:alpha on every element. There are a few problems with this:

• Performance. Each setting of “opacity” will have to recursively loop through all child elements.
• Performance * Animation fps. Yep, animating opacity in IE is plain screwed.
• Pure messiness.
• Long-term issues: what about when (if) Microsoft fixes the issue?

Don’t you just love Internet Explorer?

I keep thinking I must be wrong, and there must be some nice little workaround, CSS hack, or even the simple explanation of me just being plain wrong (I actually hope I am).

Anyone know?

But chances are, you know that, and don’t need to be convinced of the wonder of animation. So, instead, I will tell you about the beginnings of SproutCore’s support for animation.

SproutCore’s animation support currently takes the form of a mixin for views: SC.Animatable. Here are some of the features:

• Relatively fast. It can animate 1000 or so views with reasonable performance on a fast machine. Oddly, the biggest performance hurdle may now be the rendering engine (unless you are on IE—the slow script speed will kill you first).
• Uses CSS transitions where possible. Oddly, CSS transitions do not appear to be significantly faster² than JavaScript transitions (again, indicating the rendering engine could now be the bottleneck).
• Support for Layout. This almost goes without saying, as what animation framework would be worth anything if it didn’t allow you to animate the position of views?
• Support for Opacity. So you can fade things in and out.
• Support for display:none. You can add transitions to the display property, and they will simply be ignored (display gets applied immediately) except in the special case of display:none, which will only apply after the specified duration. See display:none notes
• Support for Timing Curves. You can specify curves to adjust the speed of the animation, and have them work in both JavaScript transitions and CSS transitions, or optionally, CSS transitions only.

Animating with SC.Animatable

It is quite simple. Here are the steps:

• Add “sproutcore/animation” to the required frameworks array in your Buildfile (in quotes and all).
• Mix in SC.Animatable to your view.
• Add transitions.
• Change layout, opacity, or display.

So, how about some code? First, let’s take a look at a Buildfile:

# The Contacts application Buildfile
config :contacts, :required => [:sproutcore, :"sproutcore/animation", :forms, :pomona]

Now, how about a view?

myView: SC.View.design(SC.Animatable, { // mix it in
  transitions: {
    // and add transitions
    left: .25,
    top: {duration: .25},
    width: { duration: .25, timing: SC.Animatable.TRANSITION_EASE_IN_OUT }, // with timing curve
    height: { duration: .5, timing: [0, 0, 0.58, 1.0] }, // with custom timing curve
    opacity: { duration: .5, timing: SC.Animatable.TRANSITION_CSS_EASE_IN_OUT }, // CSS-transition-only timing function (JavaScript gets linear)
    display: .75 // a bit longer than opacity 
  }
})

And finally, to animate!

myView.adjust("left", 250);
myView.set("layout", {left: 100, top: 300, width: 250, height: 340});
 
// style manipulation: a feature of SC.Animatable
myView.adjust("opacity", .5);
myView.set("style", {opacity: .7});
myView.adjust("display", "none"); // applies after .75 seconds
myView.adjust("display", "block"); // applies immediately
 
// disable animation temporarily to change something directly
myView.disableAnimation();
myView.adjust("opacity", 0).updateStyle(); // makes invisible and applies immediately.
myView.enableAnimation();
myView.adjust("opacity", 1); // fades in to visibility (applying lazily).

Pretty simple!

display:none notes

When animating the display: none property, you should add a bit of extra time to its transition.

If everything was animated using JavaScript, there would be no issue. However, because SC.Animatable takes advantage of CSS transitions where possible, and CSS transitions don’t necessarily begin immediately, if you don’t add extra time to display’s transition it could set display:none before the other transitions end (in effect, cutting them short). In the most usual case—an opacity transition—the view will start to fade out and then suddenly disappear. Again, the easiest way to fix this is by simply adding a bit of time to the transition for the display property.

The Problem with Callbacks

Currently, SC.Animatable does not have callbacks for animation completion. In fact, unless the view is being animated using JavaScript (non-WebKit browsers and Firefox earlier than 3.6, I believe), it is even impossible to tell if a view is animating.

For JavaScript-based transitions, this should not be a terribly difficult feature to add in general; there is a question of, since animations are started and stopped automatically instead of explicitly by the developer, how those callbacks would be set: should it be one per property? One per the whole view?

For CSS transitions, however, this is trickier. There is an event fired in WebKit’s implementation, but I am unable to find any documentation on Mozilla’s support for it (or, for that matter, lack thereof).

Even if support was present, it may or may not be tricky to reconcile that with the actual animation library: what if one transition ends, but a new one starts immediately after? Will the event fire after the new one begins, tricking others into thinking it has already fired? It may be more reliable to “guesstimate,” and just set a timer for a callback to go off somewhere shortly after the target time (much like the way the “display” transition is implemented).

Demo

It is not “officially” released by any means—it still needs fixes, including at least one animation-related one—but a fancy demo of the animation (used in FormView, another project I am working on) can be found here.

The code is all online too at GitHub. I am slowly making it into a full sample app for SproutCore that demonstrates animation, FormView, and Comet—and hopefully multiple back-ends (I’m working on a wacky Python one right now, and I’d like to make a node.js-based one eventually, too).

As it is, this hack could have some SEVERE side-effects, but chances are, if you are trying to debug a memory leak, you won’t care about these side-effects because everything else will be driving you MAD (and, you’ll probably be able to find these side-effects much more easily than the leak itself).

It is very simple; here is how to do it for ListItemView:

SC.mixin(SC.ListItemView, { create: function() { return new SC._ListItemView(this, arguments); } });
 
SC._ListItemView = function(base_type, args){
  base_type.call(this, args);
};
 
// for extra safety (should get around most potential side-effects):
SC.mixin(SC._ListItemView, SC.ListItemView);
 
SC._ListItemView.prototype = SC.ListItemView.prototype;

Now, ListItemViews will show up as SC._ListItemView in the heap profile. Hooray!

P.S. This revealed for me that the objects leaking were not SC.ListItemViews. I still have no idea what is leaking, and am giving up for now—but at least I’ll have better tools when I come back to it. :)

Warning: This is not tested by anyone other than me at the moment, and might prove somewhat bumpy. Feedback is very welcome!

Here is a high-level introduction of how Roots works is available here.

Very little needs to be done to add Comet. There are three main steps on the server side:

1. Get Roots and Cornelius.
2. Add views to allow clients to subscribe/connect to events.
3. Trigger events.

On the client side, there are also three major steps:

1. Get+set up Pomona.
2. Subscribe to events.
3. Receive events.

First Step

You will need at least three terminal windows—one for each server. You might as well open them first.

You will have three directories to work out of:

• Roots (or Dobby)—not much to do here :)
• SproutCore Project
• Django Project

Tip: if you want to be able to open only one TextMate window (or whatever IDE you use), you can place the Django project (and, even, Roots) in a subdirectory of your SproutCore project.

Server-Side

Getting Roots and Cornelius

First, let’s get Roots. In the Roots terminal, navigate to the folder you’d like to keep it, and:

$ git clone git://github.com/ialexi/dobby.git

And now, you can start it (assuming you have the prerequisites):

$ cd dobby
$ python dobby.py
Instating Dolores High Inquisitor of Hogwarts

There may be some deprecation warnings due to issues with Twisted, but they don’t cause problems. (Roots should be ported to node.js soon, and node.js doesn’t have these issues).

Now, get Cornelius. In the Django terminal, navigate to your Django project directory. Then run:

$ git clone git://github.com/ialexi/cornelius.git

Next, you need to add Cornelius to your Django project as an application (making it really easy to import). To do this, edit settings.py and add “cornelius” in the INSTALLED_APPS setting:

	'django.contrib.auth',
	'django.contrib.contenttypes',
	'django.contrib.sessions',
	'django.contrib.sites',
	'todos',
	'cornelius' # <- SEE! :D

Making Views to Make Connections

We can’t trust the client. As such, we do not allow the client to connect itself to any path it wants. Instead, it has to go through our Django web app. Ironically, since we’re just doing a simple application, we are in fact, going to allow the client to connect to whatever it wants (I’ll show how to change this, though).

First, you need an updated urls.py:

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
	# You don't have to do it this way, but in this example, we match
	# optional ending slashes.
	(r'^tasks/?$', "todos.views.tasks"),
	(r'^task/(?P<taskid>[0-9]+)$', "todos.views.task"),
 
	# See here:
	(r'^tasks/connect/(?P<uid>[^\s]+)$', "todos.views.connect"),
	(r'^tasks/disconnect/(?P<uid>[^\s]+)$', "todos.views.disconnect")
)

This makes tasks/connect/(CLIENT_ID) call our “connect” view, and tasks/disconnect/(CLIENT_ID) call our “disconnect” view.

Now, for the views themselves:

# Import cornelius's Dudley
from cornelius import dudley
 
# Connect
def connect(request, uid):
	paths = json.loads(request.raw_post_data)  # Pomona sends the list of paths to connect to in a JSON array.
	# note: paths is just a plain list of strings; you can loop through them and filter for security.
	dudley.connect(uid, paths)  # Dudley takes a client id and a list of paths. That's it.
 
def disconnect(request, uid):
	paths = json.loads(request.raw_post_data)
	# note: ditto regarding paths being a list of strings.
	dudley.connect(uid, paths)

Triggering Events

Django has nice post-save and post-delete events we can use to trigger events (“updates” in Roots-speak).

Here’s how we use them:

# Comet alerters
from django.db.models.signals import post_save, post_delete
def task_saved(sender, **kwargs):
	try:
		instance = kwargs["instance"]
		dudley.update("tasks", json.dumps(task_to_raw(instance)))
	except:
		pass
 
def task_destroyed(sender, **kwargs):
	try:
		instance = kwargs["instance"]
		data = task_to_raw(instance)
		data["DELETE"] = True
		dudley.update("tasks", json.dumps(data))
	except:
		pass
post_save.connect(task_saved, sender=Task)
post_delete.connect(task_destroyed, sender=Task)

Note how we once again use task_to_raw.

And now, the server-side is done!

Of course, start it with:

$ python manage.py runserver

Client Side

Getting and Setting Up Pomona

In your SproutCore terminal, navigate to your SproutCore project. Then, get Pomona and put it in the “frameworks” folder:

$ git clone git://github.com/ialexi/pomona.git frameworks/pomona

Next, just like you add the project in Django, you need to add the framework to your SproutCore project. To accomplish this, you edit the “config” line of “Buildfile” to look like this:

config :all, :required => [:sproutcore, :pomona]

You changed it from the solitary :sproutcore, to the array [:sproutcore, :pomona].

Next, you need to proxy Roots’ long-polling server. Just add this line at the end of Buildfile after the other two proxy lines:

proxy "/comet/", :to => "localhost:8008", :url=>"/"

Subscribing to Events

There are two things that have to happen to subscribe to events: create and configure an instance of the long-poller, and call connect().

The easiest place to do this is in an init function in our data source. Just place this code in the DataSource definition (preferably at the top).

  init: function(){
    // DataSource has no init right now, but what if it adds one?
    // so, call super function first.
    sc_super(); 
 
    // needs proxy /comet/ to dobby
    this.firenze = Pomona.Firenze.create({    // Firenze is the name of the long-poll system.
      connectUrl: "/tasks/connect/%@",        // %@ is replaced with the client id
      disconnectUrl: "/tasks/disconnect/%@"
    });
 
    // tell it to call this.taskReceived when a message is received on path "tasks"
    this.firenze.connect("tasks", this, "taskReceived");
  },

The connectUrl/disconnectUrl parameters tell Pomona what URLs to send connect and disconnect requests to. All it does is send a JSON array of path (event) names in a JSON array). It will automatically re-send these messages if the connection with the long-polling server is interrupted and a new connection (with a new id) is created.

All that’s left now is to receive messages!

Receiving Messages

Receiving messages is simple: we just implement the “taskReceived” function we told it about earlier.

  taskReceived: function(path, message) {
    if (message.trim() === "") return;  // the first time, we receive "" to confirm connection
    var data = JSON.parse(message);   // we sent a JSON-encoded message from Python
 
    if (data.DELETE) {
      // We set DELETE if the record needed deleting
      Todos.store.pushDestroy(Todos.Task, data.guid);
    } else {
      // otherwise, we should just re-load that record.
      Todos.store.loadRecords(Todos.Task, [data]);
    } 
  },

That’s All!

Start sc-server, open two browsers, both pointing at http://localhost:4020/todos, and hopefully, you’ll have Comet.

There may be some bumps—if anyone is willing to test and offer feedback, please do so!

Good luck!

Now, the comparatively exciting: The SproutCore Animation mixin now supports timing curves!

There are two ways to set the timing curve to use: globally and locally. The global timing curve (null by default) is used if there is no local timing curve—in essence, the global timing curve is the default timing curve (in fact, it is named defaultTimingFunction).

aView: SC.LabelView.design(Animate.Animatable, {
    transitions: {
        left: .25,
        top: {duration: .25},
        width: { duration: .25, timing: Animate.TIMING_EASE_IN_OUT }, // with timing curve
        height: { duration: .5, timing: [0, 0, 0.58, 1.0] } // with custom timing curve
    }
})

Timing curves are cubic beziér curves, as used in CSS Transitions. They can be used as CSS-only, or, if you are willing to take a bit of a JavaScript performance hit, in both CSS and JavaScript. In fact, the JavaScript variety’s code is based on WebKit’s actual code for handling cubic beziér curves.

The pre-defined timing curves are identical to the CSS timing functions:

// CSS-only
TRANSITION_NONE: "linear",
TRANSITION_CSS_EASE: "ease",
TRANSITION_CSS_EASE_IN: "ease-in",
TRANSITION_CSS_EASE_OUT: "ease-out",
TRANSITION_CSS_EASE_OUT: "ease-in-out",
 
// JavaScript-enabled
TRANSITION_EASE: [0.25, 0.1, 0.25, 1.0],
TRANSITION_LINEAR: [0.0, 0.0, 1.0, 1.0],
TRANSITION_EASE_IN: [0.42, 0.0, 1.0, 1.0],
TRANSITION_EASE_OUT: [0, 0, 0.58, 1.0],
TRANSITION_EASE_IN_OUT: [0.42, 0, 0.58, 1.0]

The implementation is somewhat simple; if the timing function is a string, it is set directly into the transition-timing-function CSS property—and JavaScript animations ignore it (and thus work linearly). Otherwise, a cubic-bezier() is inserted into the CSS, and the JavaScript implementation is set up.

The calculations for the cubic beziér curves involve loops, and must be calculated every frame—they have a significant potential to slow things down (it may be wise to have a pre-calculated option as well at some point to help alleviate this). As such, you may not want to use the JavaScript variety unless you are animating relatively few elements.

I don’t know if anyone is using the Animate mixin (aside from me) but if anyone is, I hope they enjoy this new feature!

But I need messaging.

I don’t care about queuing or persistence. For web applications (what I work on) messages should be delivered as quickly as possible. Any “queues” can be in-memory, and any message should not remain in a queue for more than a minute—if the client was disconnected for any duration, it would likely be better off re-downloading that receiving incremental updates.

So, whatever these systems do, they seem too complicated (I could be wrong—as I said, I have trouble understanding them).

My requirements:

• Normal Authentication. Clients should go through the “normal” web app to subscribe to events.
• Easy. It should be very simple and easy to understand.
• Quick. I should be able to add Comet to an app in ten to fifteen minutes, maximum.

I found out that it is not only possible to write messaging servers on one’s own—it is relatively easy. So I wrote one.

I’ll stop the backstory here, though there is plenty more—tell me if you want any of the boring details about Dolores and the rest.

Roots

Roots—codenamed Dobby after the Harry Potter character—is a messaging server that has a built-in long-polling server (among several other things).

Roots is made up of many small message-passing pieces. They plug together, just like Lego pieces. Each piece is simple, and the connection between the pieces are even simpler: a single function, called “update.”

If you are interested, I’ll go over that more thoroughly in “Implementation.”

How Roots is Used

Above All, Roots is Easy.

It takes me about fifteen minutes to use Roots to add push to a SproutCore application (starting with a fresh clone of Roots—which, by the way, does not need any configuration for testing). It should only take me five minutes, but I am often a bit slow of a coder.

There is a brief semi-tutorial on GitHub. The following is based on that tutorial, but has some extra background information.

So, a bird’s-eye view: unless you implement the server-side in Roots itself, you will have three components in any application: back-end (Rails, Django, etc.), front-end (SproutCore), and Roots.

• Client—such as Pomona, the SproutCore framework for Roots) connects to a Roots server.
• Roots sends the client (Pomona) an id.
• The client calls predefined URL to connect to events.
  • The URLs are part of the back-end (Django, etc.)
  • The ID is sent with these requests.
  • Clients (Pomona) usually will keep track of what server-side events you are listening to and can reconnect automatically if the Dobby connection is interrupted—you just provide the client with the URLs and the events to listen to.
• Back-end tells Roots to connect client to events—and can perform any authorization it wishes.
• Back-end sends updates to Roots.
• Client receives notifications—everyone’s Happy!!!

What You Do (for SproutCore)

You don’t have to do much:

1. Add Pomona to your SproutCore project.
2. Add a Roots connector to your server-side project:
   • Cornelius for Python
   • Others as I add them (I plan Ruby and PHP)
   • Implement your own (the Python version of the better protocol—Dudley—is 45 lines counting whitespace and comments).
3. “Update” Roots (call update(path, message) from your back-end—Django has handy model post-save signals you can use).
4. Add some URLs to your back-end that connect clients.
   • URLs accept client ID in them (/my/connect/AN_ID_HERE or /my/connect.src?id=AN_ID_HERE)
   • URLs should accept POST of a simple JSON array of path/event names.
   • For each path/event/whatever you want to call it, call connect(id, path) on your Roots connector.
   • Initialize Pomona and connect to Roots in your SproutCore Data Source.
   • Accept incoming data!

A more detailed tutorial is here on GitHub with the rest of Dobby (Roots).

Open Question: Would anyone like a tutorial on setting up a Django back-end for the SproutCore Todos tutorial, with an extra step of adding Comet at the end? Done!

Implementation

Roots/Dobby is currently written in Python. I am working on a rewrite in node.js, because node.js is super cool—and, secondarily, it means that some of the same code used in the server (for instance, the message dispatch code) could be used on the client.

Roots has many small parts that hook together in a very simple way. At Roots’s core is Thestral, a simple interface that requires implementors to do two things: have an id and implement a single method: update(sender, path, message)—where sender is an originator, path is an event name, and message is some data to send.

Here are some of the components:

• Dolores: This is the main controller. It assigns IDs to all Thestral instances. It itself is a Thestral instance, and sends its updates to “delegates”.
• Pig: An “Owl,” or, really, a dispatcher; it knows who receives what message. It is often one of Dolores’s delegates. Specially-formed messages, tell it to connect certain Thestral ids with certain events—for instance, the event “::connect” with message “12345->my/data” would connect Thestral “12345″ to “my/data”.
• Imperio. A somewhat pathetic text-based protocol, with accompanying receiver server (a bit like Dudley, which should be used instead). In addition to reading from a server, Imperio supports writing to anything with a write() method, and as such, is used for logging as a delegate of Dolores.
• Dudley. Dudley is not a delegate of Dolores. Rather, Dolores can be its “delegate” (or, in this case, “receiver”). Dudley is an HTTP server, and receives messages over HTTP and funnels them to a receivers (Thestral implementation), and Dolores is its default receiver.
• Firenze. Firenze, like Dudley, is an HTTP server; but instead of being a receiving server, it is a long-polling push server. It is not usually Dolores’s delegate—you don’t want every client to get every message. Instead, Firenze merely registers itself with Dolores to get an ID, and lets others register it (for instance, a client could send Dudley a message, which, through Dolores, would be received by Pig to make the connection).

Above all, it is simple. The longest of these pieces is Firenze, at 280 lines of code (50 of which are intro comments I used to explain it to myself and spec it while planning).

That’s All!

I hope you find this helpful. I am excited about porting Roots to node.js; progress is somewhat slow, as I am quite busy (I am a student, and finals for all four classes tomorrow!)

What I am most looking forward to is how Pig (the dispatcher) could use the same code in both the client (Pomona) and the server—the routing is quite similar; in one case, you want to route to handlers/callbacks, in the other, to update functions on Thestral instances—pretty similar; even identical.

I am also looking forward to experimenting with two-way push, where all data is transferred through push—completely eradicating the expectation of a response to a request, and providing only a single receive/send code path on both client and server.

Anyway, I think this is all super cool. :)

Thanks to Endash for the nice title. :) Roots (called Dobby in development) is available on GitHub.

P.S. I like the name Dobby, but Roots is better P.R.

The current version only works for layout properties, and does not yet work for centerX and centerY properties (they used to work, but some of the performance optimizations have made it slightly more tricky—I’ll be adding it back soon, though).

I decided to see how fast the code was in different browsers. The tests were done using a test application which generated a specified number of views, and then, once per second, updated a “frames per second” display. The measuring is somewhat subjective, as I have to deduce, based on consistency (or lack thereof) in the numbers, what the frame rate actually is. For the most part, they were pretty consistent, but the WebKit browsers at really low numbers of views (and really high frame rates) could be quite inconsistent at times.

I ran the tests on two separate machines:

• Mac OS X Snow Leopard on MacBook Pro 15″ Core 2 Duo 2.33Gz w/2GB RAM. Lots of open programs, including iTunes. Not as scientific as would be optimal, but it is my work machine.
• Windows XP on Pentium 4 3.20GHz w/2GB RAM. Only the browser was open.

Browsers tested (note that my Firefox was OLD):

• Safari 4.0.3 for Mac
• Firefox 3.5.3 for Mac
• Chromium 4.0.223.3 (29380) for Mac
• Internet Explorer 8
• Firefox 3.0.1 for Windows (oops. Should have upgraded first. Remind me to update numbers on Friday)
• Safari 4.0.3 for Windows
• Chrome 3.0.195.27 for Windows

Here is the data:

Data collected during testing of the different browsers

That’s boring. Where are the pictures?

All Browsers

Even here, you can tell that Chrome and Chromium are the best performers for small numbers of views. However, for larger numbers of views, Safari on Mac was a very clear winner, running at 12 frames per second for 2000 LabelViews..

Predictably, Internet Explorer was slowest. I didn’t bother to run all the tests for it.

Windows Browsers

This chart shows only the Windows browsers. Again, you can tell IE is very slow. Chrome is very very fast. Safari is pretty good. My out-of-date Firefox is not always that much faster than IE; it will be interesting to see how Firefox 3.5 fares.

Notice the dip in performance for Safari at around 300? It briefly does worse than Firefox. It quickly levels off, though, and is second only to Chrome.

Mac Browsers

And, of course, the best for last. Note how we see the same dip in performance for Safari—though it does not dip below Firefox; it would have dipped below Chromium, were it not already below it. Again, though, it leveled out faster than Chromium.

I always wanted to do a performance chart, but now that I have… it’s a lot of work (about 57 or so data points there… each measured separately).

Question Is the difference between Safari and Chromium completely caused by Google’s V8 JavaScript engine, or are there a few other differences?

Well, here are your options:

1. Read the whole article. Could be amusing, if I’m having a bad writing day.
2. Skip to the download and “how to use.” No, I’m not going to explain the code. Well, not here, at any rate. I’ll explain it in the code itself. Yes, of course there are comments.

What is Spriting?

Example Sprited Images

The goal of spriting is to reduce the effect of latency on your web app’s performance.

To your left is an example set of sprited images.

Using a Script

You may thing that combining several images into one larger image might be a bit time-consuming and, overall, a tad challenging, especially if you are often updating the individual images.

You are not alone. I feel the same way.

However, I do know a little about writing scripts—even if I’d like to know a lot more; I’m still only learning Python. So, there is a simple answer:

Write a darn script!

The Product

If you just want the script and how to use it, you’re in luck. Because there are, in fact, some comments in the script, I’ll leave the explanation of how the code works for there.

You can download the code from GitHub.

The script is written in Python. It requires: Either: Python 2.6+ or Python 2.5 with simplejson installed PIL (Python Imaging Library)

Very briefly, here is what it does:

• Takes a “sets” folder, which should have sub-folder sets of icons to be sprited.
• Takes an output folder, under which it will create new set folders containing CSS and image files.
• Combines images under a maximum size (128×128 by default—see Configuration) into a sprites.png file in the output set folder.
• Creates CSS referencing these images using a URL template (SproutCore oriented at first—see URL)

Sets

You often might have more than one set of icons. For instance, you could have a main set, and then an alternate set that you only want to load on demand. You still want that additional set to be sprited.

Or, perhaps, you may have images meant for repeating backgrounds, but that you still want to sprite.

To facilitate this, the spriting script takes, as its first argument, the location to a sets folder. You put your sets as subfolders into this folder. For instance, this could be your folder layout:

my-sets
	common
		delete-32.png
		delete-64.png
		refresh-32.png
		refresh-64.png
		refresh-512.png
	repeat-x
		config.js       — see Configuration
		toolbar.png
		footer.png
		header.png
	odd-feature
		some-icon.png
		other-icon.png

URLs

The CSS has to reference the images. Only problem: it doesn’t know where those images are.

Usually, you’d just be able to use paths relative to the StyleSheet. However, if you are using SproutCore, this won’t work because it moves around all the CSS and JavaScript.

With SproutCore, you need something more like:

static_url('images/set/sprites.png')

This is what the script does by default. Just like above. It uses a URL template of

static_url('images/{set}/{image}')

It is a string which will be passed through the Python format function, with set and image as arguments.

Configuration

There are a few things that are configurable. Configuration is done per-set.

Configuration files are JSON files, and are very simple. They are optional, and take at most four parameters:

• max-size: Default: 128.
  The maximum size for sprited images. Images above this size will be put as separate images. Useful if you have some really high-res icons you don’t want to sprite, but want to keep with the set.

• repeat: Default: “none”; can also be “x” or “y”.
  Determines the repeat mode. If repeat is “x,” the sprites will be laid out in rows; if “y,” the sprites will be laid out in columns. The generated CSS will include repeat-x or repeat-y, respectively.

Note that all images in a repeat-x set must be the same width, and all images in a repeat-y set must be the same height. The width or height of these images should be set using repeat-width and repeat height, which are discussed below.

• repeat-width: Default: 32.
  If repeat=“x,” the width of the repeat images. If your repetition does not require a pattern, you could set this to 1.

• repeat-height: See that lovely summary of repeat-width above? Well, this is the same, but for y/height.

The CSS

As you may know, SproutCore automatically includes any CSS files. So, since this generates CSS files (and, if you provide the right argument, puts them directly into a SproutCore-watched folder), the CSS is automatically added. So, how do you use it?

Very simply. The script generates CSS rules in this format:

.set-name .icon-name.icon, .set-name .icon-name.icon { /* CSS */ }

For example, to show “refresh-64″ icon in set “common”, you’d do something like this:

ImageView.design({
  layout: { left: 100, top: 100, width: 64, height: 64 },
  value: "common refresh-64 icon" // using SproutCore's built-in className support for spriting
}

Or, as you may have noticed from the rule above, you can accomplish some basic theming very easily by treating set names as themes:

View.design({
  layout: {left: 100, top:100, width:256, height: 256},
  classNames: ["common"], // the theme
  childViews: ["styledView"],
  styledView: ImageView.design({
    layout: { left: 100, top: 100, width: 64, height: 64 },
    value: "refresh-64 icon" // using SproutCore's built-in className support for spriting
  })
})

Nice and simple, eh?

They need to be Windows Services.

Thankfully, it isn’t actually too hard. You just need a couple of Python packages (which I actually don’t remember installing, so they may have come with Twisted or Python), and then all you have to do is write a couple of very simple scripts. Here are mine:

Orbited Service

import OrbitedManager # a copy of orbited.start with some very minor modifications, which I'll include after the break
import time
 
# Service Utilities
import win32serviceutil
import win32service
import win32event
 
class WindowsService(win32serviceutil.ServiceFramework):
	_svc_name_ = "Orbited"
	_svc_display_name_ = "Orbited Server"
 
	def __init__(self, args):
		win32serviceutil.ServiceFramework.__init__(self, args)
		self.hWaitStop = win32event.CreateEvent(None, 0, 0, None)
 
	def SvcStop(self):
		self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
		win32event.SetEvent(self.hWaitStop)
 
	def SvcDoRun(self):
		import servicemanager
		OrbitedManager.start()
		while True:
			retval = win32event.WaitForSingleObject(self.hWaitStop, 10)
			if not retval == win32event.WAIT_TIMEOUT:
				OrbitedManager.stop()
				break
				time.sleep(5.0)
 
 
if __name__=='__main__':
	win32serviceutil.HandleCommandLine(WindowsService)

Dolores Service

import Dolores
import time
 
# Service Utilities
import win32serviceutil
import win32service
import win32event
 
class WindowsService(win32serviceutil.ServiceFramework):
	_svc_name_ = "Dolores"
	_svc_display_name_ = "Dolores Server"
 
	def __init__(self, args):
		win32serviceutil.ServiceFramework.__init__(self, args)
		self.hWaitStop = win32event.CreateEvent(None, 0, 0, None)
 
	def SvcStop(self):
		self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
		win32event.SetEvent(self.hWaitStop)
 
	def SvcDoRun(self):
		import servicemanager
		Dolores.start()
		while True:
			retval = win32event.WaitForSingleObject(self.hWaitStop, 10)
			if not retval == win32event.WAIT_TIMEOUT:
				Dolores.stop()
				break
				time.sleep(5.0)
 
 
if __name__=='__main__':
	win32serviceutil.HandleCommandLine(WindowsService)

That’s the basics, but as you may have noticed, I also changed Orbited’s start script. I did this because the original did not play nicely with threads.

Instead of changing it in its original location in the filesystem, I created a copy of it in the local directory (as you can see, I’m not importing Orbited.OrbitedManager).

Before overwhelming you with a wall of code, I’ll explain what I changed. It is actually quite simple:

1. First, some imports at the top:

   import orbited
   import threading
   import time

2. Since the file is no longer “start.py” in the Orbited package directory, the static files path needs changing (just find the line and change it):

   static_files = static.File(os.path.join(os.path.dirname(orbited.__path__[0]), 'orbited/static'))

3. And, since we’re going to start the reactor manually, we need to remove the auto-start portion:

   # REMOVE THIS PART:
       if options.profile:
           import hotshot
           prof = hotshot.Profile("orbited.profile")
           logger.info("running Orbited in profile mode")
           logger.info("for information on profiler, see http://orbited.org/wiki/Profiler")
           prof.runcall(reactor.run)
           prof.close()
       else:
           reactor.run()

4. Finally, I added a bit to the bottom, replacing the lines that call “main()”. It arranges to run Orbited (or any Twisted service) in a separate thread:

   def thread_start():
   	main() # initializes the reactor
   	from twisted.internet import reactor
   	reactor.run(installSignalHandlers=0)
   	print "Crashed into Earth's Surface."
    
   orbited_thread = None
   def start():
   	print "Starting Orbited..."
   	orbited_thread = threading.Thread(target=thread_start)
   	orbited_thread.start()
   	print "In Orbit."
    
   def stop_reactor():
   	reactor.stop()
    
   def stop():
   	reactor.callFromThread(stop_reactor)
    
   if __name__ == "__main__":
   	start()
   	run = True
   	while run:
   		try:
   			time.sleep(5)
   		except KeyboardInterrupt:
   			from twisted.internet import reactor
   			stop()
   			run = False

The Raw OrbitedManager.py File

import os
import sys
import urlparse
from orbited import __version__ as version
from orbited import config
from orbited import logging
import orbited
import threading
import time
 
# NB: this is set after we load the configuration at "main".
logger = None
 
def _import(name):
    module_import = name.rsplit('.', 1)[0]
    return reduce(getattr, name.split('.')[1:], __import__(module_import))
 
def _setup_protocols(root):
    from twisted.internet import reactor
    protocols = [
        #child_path config_key  port_class_import,              factory_class_import
        ('tcp',     'proxy',    'orbited.cometsession.Port',    'orbited.proxy.ProxyFactory'),
    ]
    for child_path, config_key, port_class_import, factory_class_import in protocols:
        if config.map['[global]'].get('%s.enabled' % config_key) == '1':
            port_class = _import(port_class_import)
            factory_class = _import(factory_class_import)
            reactor.listenWith(port_class, factory=factory_class(), resource=root, childName=child_path)
            logger.info('%s protocol active' % config_key)
 
def _setup_static(root, config):
    from twisted.web import static
    for key, val in config['[static]'].items():
        if key == 'INDEX':
            key = ''
        if root.getStaticEntity(key):
            logger.error("cannot mount static directory with reserved name %s" % key)
            sys.exit(1)
        root.putChild(key, static.File(val))
 
def main():
    try:
        import twisted
    except ImportError:
        print "Orbited requires Twisted, which is not installed. See http://twistedmatrix.com/trac/ for installation instructions."
        sys.exit(1)
 
    #################
    # This corrects a bug in Twisted 8.2.0 for certain Python 2.6 builds on Windows
    #   Twisted ticket: http://twistedmatrix.com/trac/ticket/3868
    #     -mario
    try:
        from twisted.python import lockfile
    except ImportError:
        from orbited import __path__ as orbited_path
        sys.path.append(os.path.join(orbited_path[0],"hotfixes","win32api"))
        from twisted.python import lockfile
        lockfile.kill = None
    #################
 
    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option(
        "-c",
        "--config",
        dest="config",
        default=None,
        help="path to configuration file"
    )
    parser.add_option(
        "-v",
        "--version",
        dest="version",
        action="store_true",
        default=False,
        help="print Orbited version"
    )
    parser.add_option(
        "-p",
        "--profile",
        dest="profile",
        action="store_true",
        default=False,
        help="run Orbited with a profiler"
    )
    parser.add_option(
        "-q",
        "--quickstart",
        dest="quickstart",
        action="store_true",
        default=False,
        help="run Orbited on port 8000 and MorbidQ on port 61613"
    )
 
    (options, args) = parser.parse_args()
 
    if args:
        print 'the "orbited" command does not accept positional arguments. type "orbited -h" for options.'
        sys.exit(1)
 
    if options.version:
        print "Orbited version: %s" % (version,)
        sys.exit(0)
 
    if options.quickstart:
        config.map['[listen]'].append('http://:8000')
        config.map['[listen]'].append('stomp://:61613')
        config.map['[access]'][('localhost',61613)] = ['*']
        print "Quickstarting Orbited"
    else:
        # load configuration from configuration
        # file and from command line arguments.
        config.setup(options=options)
 
    logging.setup(config.map)
 
    # we can now safely get loggers.
    global logger; logger = logging.get_logger('orbited.start')
 
 
    # NB: we need to install the reactor before using twisted.
    reactor_name = config.map['[global]'].get('reactor')
    if reactor_name:
        install = _import('twisted.internet.%sreactor.install' % reactor_name)
        install()
        logger.info('using %s reactor' % reactor_name)
 
    ############
    # This crude garbage corrects a bug in twisted
    #   Orbited ticket: http://orbited.org/ticket/111
    #   Twisted ticket: http://twistedmatrix.com/trac/ticket/2447
    import twisted.web.http
    twisted.web.http.HTTPChannel.setTimeout = lambda self, arg: None
    twisted.web.http.HTTPChannel.resetTimeout = lambda self: None
    ############
 
    from twisted.internet import reactor
    from twisted.web import resource
    from twisted.web import server
    from twisted.web import static
    import orbited.system
 
    root = resource.Resource()
    static_files = static.File(os.path.join(os.path.dirname(orbited.__path__[0]), 'orbited/static'))
    root.putChild('static', static_files)
    root.putChild('system', orbited.system.SystemResource())
 
    if config.map['[test]']['stompdispatcher.enabled'] == '1':
        logger.info('stompdispatcher enabled')
 
    #static_files.putChild('orbited.swf', static.File(os.path.join(os.path.dirname(__file__), 'flash', 'orbited.swf')))
    site = server.Site(root)
 
    _setup_protocols(root)
    _setup_static(root, config.map)
    start_listening(site, config.map, logger)
 
    # switch uid and gid to configured user and group.
    if os.name == 'posix' and os.getuid() == 0:
        user = config.map['[global]'].get('user')
        group = config.map['[global]'].get('group')
        if user:
            import pwd
            import grp
            try:
                pw = pwd.getpwnam(user)
                uid = pw.pw_uid
                if group:
                    gr = grp.getgrnam(group)
                    gid = gr.gr_gid
                else:
                    gid = pw.pw_gid
                    gr = grp.getgrgid(gid)
                    group = gr.gr_name
            except Exception, e:
                logger.error('Aborting; Unknown user or group: %s' % e)
                sys.exit(1)
            logger.info('switching to user %s (uid=%d) and group %s (gid=%d)' % (user, uid, group, gid))
            os.setgid(gid)
            os.setuid(uid)
        else:
            logger.error('Aborting; You must define a user (and optionally a group) in the configuration file.')
            sys.exit(1)
 
 
def start_listening(site, config, logger):
    from twisted.internet import reactor
    from twisted.internet import protocol as protocol_module
    # allow stomp:// URIs to be parsed by urlparse
    urlparse.uses_netloc.append("stomp")
    # allow test server URIs to be parsed by urlparse
    from orbited.servers import test_servers
    for protocol in test_servers:
        urlparse.uses_netloc.append(protocol)
 
    for addr in config['[listen]']:
        if addr.startswith("stomp"):
            stompConfig = ""
            if " " in addr:
                addr, stompConfig = addr.split(" ",1)
        url = urlparse.urlparse(addr)
        hostname = url.hostname or ''
        if url.scheme == 'stomp':
            logger.info('Listening stomp@%s' % url.port)
            from morbid import get_stomp_factory
            morbid_instance = get_stomp_factory(stompConfig)
            config['morbid_instance'] = morbid_instance
            reactor.listenTCP(url.port, morbid_instance, interface=hostname)
        elif url.scheme == 'http':
            logger.info('Listening http@%s' % url.port)
            reactor.listenTCP(url.port, site, interface=hostname)
        elif url.scheme == 'https':
            from twisted.internet import ssl
            crt = config['[ssl]']['crt']
            key = config['[ssl]']['key']
            try:
                ssl_context = ssl.DefaultOpenSSLContextFactory(key, crt)
            except ImportError:
                raise
            except:
                logger.error("Error opening key or crt file: %s, %s" % (key, crt))
                sys.exit(1)
            logger.info('Listening https@%s (%s, %s)' % (url.port, key, crt))
            reactor.listenSSL(url.port, site, ssl_context, interface=hostname)
        elif url.scheme in test_servers:
            test_factory = protocol_module.ServerFactory()
            test_factory.protocol = test_servers[url.scheme]
            logger.info("Listening %s@%s"%(url.scheme, url.port))
            reactor.listenTCP(url.port, test_factory)
            if url.scheme == 'monitor':
                config['globalVars']['monitoring'] = url.port
        else:
            logger.error("Invalid Listen URI: %s" % addr)
            sys.exit(1)
 
 
def thread_start():
	main()
	from twisted.internet import reactor
	reactor.run(installSignalHandlers=0)
	print "Crashed into Earth's Surface."
 
 
orbited_thread = None
def start():
	print "Starting Orbited..."
	dolores_thread = threading.Thread(target=thread_start)
	dolores_thread.start()
	print "In Orbit."
 
def stop_reactor():
	reactor.stop()
 
def stop():
	reactor.callFromThread(stop_reactor)
 
if __name__ == "__main__":
	start()
	run = True
	while run:
		try:
			time.sleep(5)
		except KeyboardInterrupt:
			from twisted.internet import reactor
			stop()
			run = False

So, What Do I Do?

You should just need to put the windows service script and the OrbitedManager.py script in the same directory, and then run the windows service script from the command line. If you run it with no arguments, I believe it will give you an overview of available options, including the option to install.

I hope someone can find this helpful.

Update: I added some clarification in the middle, discussing high-level about the replacement of Orbited’s start module, and a bit at the end about what to do.

I have been working on a web application. I’ll hopefully be able to post the application soon.

I needed the server to be able to send updates to the client via Comet. I’d never done any Comet before, so I wasn’t sure what to do.

A lot of articles had examples making use of message queues and who knows what else. They were a tad overwhelming. While a message queue of some sort may eventually be a good idea, for now, all I needed to do was push a non-vital progress indicator for a job (15%, 20%, 30%, and so on) to the client so the user could see what was happening. I wanted more than one job to be supported, and the overall system should eventually allow sending updates when elements in the user’s filesystem are updated.

So, I’d like to be able to send:

UPDATE process/at/my/process/path; {progress:.5}
UPDATE file/at/my/file/path.txt

In short, I’d like to send paths, along (sometimes) with little tiny messages.

Also, each instance of the web app should only receive updates to paths they are listening to, and they should only be allowed to listen to paths they actually have access to. Or, at least, that should be the case once I implement permission management in the app &emdash; right now, anything goes, which is fine for the moment because it is limited to test use on our local network.

So, I made a little script, called Dolores, which handles all of this, and another script, named Cornelius, which connects to it (incidentally, there are two Corneliuses: a Python one, and a JavaScript one).

I have posted it here in case anyone is interested. I used Orbited in JavaScript to connect to the server. In a separate post in just a few moments, I’ll write about something a tad more useful than the Dolores & Cornelius code I’m writing about here: how to run the Orbited (and, actually, Dolores) as a Windows service.

Disclaimer: This is for interest only. I’m proud of it because I managed to make it, not because I actually think it is wonderful.

Before getting to the code, let me explain the API, which, if you have the server running, you can access manually using telnet:

You connect, and immediately receive:

I, Dolores, High Inquisitor, Hogwarts.
{A-THREAD-ID-HERE}

That thread ID can then be used by a controller thread to connect you to paths.

Speaking of controllers, to control, you’d just make a file named “control-{THREAD-ID}” in a folder named “threads” relative to Dolores.py. Then, you’d send:

CONTROL

Now, to connect or disconnect a thread to a path:

CONNECT {THREAD-ID} some/path/or/another
DISCONNECT {THREAD-ID} some/path/or/another

In the web application, a django view handles the connection of a client (who sends its thread id along with the connection request). By only allowing controllers to create the connections, the client is not able to listen in to places it isn’t allowed.

And to send an update to a path:

UPDATE some/path/or/another; {some: message, may: go, right: here, format: "any"}

Any listening thread will immediately receive:

UPDATE some/path/or/another; {some: message, may: go, right: here, format: "any"}

Just as you sent it.

And yes, part of the reason it is named Dolores (the name of a particularly nasty character in the Harry Potter universe) is because I believe it to be a somewhat ugly solution. But unlike the HP character, it works. The HP character&emdash;let’s not go there.

Now, without further ado:

from twisted.internet.protocol import Protocol, Factory
from twisted.internet import reactor
from twisted.protocols.basic import LineReceiver
import random, string
import os, os.path
import threading
import time
 
# This is Delores the High Inquisitor.
 
# Dolores is a series of tubes. To prevent clogging, there are separate tubes,
# rather than one big pipe everyone might get stuck in.
 
# A user can be connected to a tube. This allows the user to receive notifications
# through said tubes.
 
# The pipe server is not made for actual COMET, believe it or not. There is no
# persistence or anything. It is as simple as possible. Instead, we will try to
# use Orbited to make a nice connection between Dolores and the client.
 
# I don't know how this will hold up performance-wise, but it is simple enough
# that I think it will work for now.
 
# API:
# There are two kinds of connections: control and client. The api 
# Creating a connection immediately results in a response with a thread id. Thread
# ids consist of a few main parts: IPADDRESS-THREAD#-SECRET
# Where thread# is a sequential thread number, IPADDRESS is the address of the client,
# and SECRET is a random string of bytes made for the thread.
 
# Clients connecting should check first for a string starting with "I,", which means they
# successfully connected. They should then read another string with their thread id.
 
#	CONTROL
#			Attempts to make the thread a controller. This only works if a file
#			named "control-" and the thread id is in the "threads" folder (relative
#			to the Dolores.py file -- messy, I know)
#
#	CONNECT UID PATH 			(controller only)
#			Connects the thread with id UID to the specified path.
#
#	DISCONNECT UID PATH			(controller only)
#			Disconnects the thread with id UID from the specified path.
#
#	UPDATE PATH MESSAGE 		(controller only)
#			Sens a message regarding the path. Please keep the message twitter length.
#
#	CRASH UID					(controller only)
#			Aborts a thread. Could be used for testing whole (un-optimized/cometized) reload.
#
 
 
class Comet(LineReceiver):
	def __init__(self):
		self.listening = set()
		self.controls = False
 
	def connectionMade(self):
		self.transport.write("I, Dolores, High Inquisitor, Hogwarts.\n")
 
		secret = ""
		for i in range(32):
			secret += random.choice(string.ascii_letters + string.digits)
 
		self.id = str(self.transport.getPeer().host) + "-" + str(self.factory.nextThreadNumber()) + "-" + secret
		print "New Thread " + self.id
 
		self.transport.write(self.id + "\n")
		self.factory.comets[self.id] = self;
 
	def control(self):
		# if the file exists, do it.
		if os.path.exists(os.path.join(os.path.dirname(__file__), "threads", "control-" + self.id)):
			self.controls = True
			os.remove(os.path.join(os.path.dirname(__file__), "threads", "control-" + self.id))
		else:
			self.controls = False
 
	def connectionLost(self, reason):
		print "Closed Thread " + self.id
		del self.factory.comets[self.id]
		for listen in self.listening:
			self.factory.deregister(listen, self)
 
	def listen(self, path):
		self.factory.register(path.strip(), self)
		self.listening.add(path.strip())
 
	def ignore(self, path):
		self.factory.deregister(path.strip(), self)
		if path.strip() in self.listening:
				self.listening.remove(path.strip())
 
	def lineReceived(self, data):
		if data.startswith("CONNECT"):
			if not self.controls:
				self.transport.write("NOALLOW\n")
				return
			try:
				uid, path = data[7:].strip().split(" ", 1)
				uid = uid.strip()
				path = path.strip()
				print "Connect " + uid + " to " + path
 
				self.factory.comets[uid].listen(path)
				self.listening.add(data[6:].strip())
				self.transport.write("SUCCESS\n")
			except:
				print "Failed a connect attempt."
				self.transport.write("FAIL\n")
 
		elif data.startswith("DISCONNECT"):
			if not self.controls:
				self.transport.write("NOALLOW\n")
				return
			try:
				uid, path = data[10:].strip().split(" ", 1)
				uid = uid.strip()
				path = path.strip()
				if uid in self.factory.comets:
					self.factory.comets[uid].ignore(path)
					self.transport.write("SUCCESS")
					return
			except:
				pass
			self.transport.write("FAIL")
 
		elif data.startswith("CRASH"):
			if not self.controls:
				self.transport.write("NOALLOW\n")
				return
			try:
				uid = data[5:].strip()
				if uid in self.factory.comets:
					self.factory.comets[uid].transport.loseConnection()
				self.transport.write("SUCCESS")
			except:
				self.transport.write("FAIL")
 
		elif data.startswith("EXIT"):
			self.transport.loseConnection()
 
		elif data.startswith("UPDATE"):
			if not self.controls:
				self.transport.write("NOALLOW\n")
				return
			try:
				pieces = data[6:].split(";",1)
				path = pieces[0]
				message = ""
				if len(pieces) > 1:
					message = pieces[1]
				print "UPDATE " + path.strip() + ": " + message.strip()
				self.factory.message(path.strip(), message.strip())
				self.transport.write("SUCCESS")
			except:
				self.transport.write("FAIL\n")
 
		elif data.startswith("ALL"):
			if not self.controls:
				self.transport.write("NOALLOW\n")
				return
			try:
				path = data[3:]
				for i in self.factory.comets:
					self.factory.comets[i].sendMessage(path)
				self.transport.write("SUCCESS")
			except:
				self.transport.write("FAIL")
 
		elif data.startswith("CONTROL"):
			self.control()
			if not self.controls:
				self.transport.write("NOALLOW\n")
				return
 
	def sendMessage(self, path, message):
		self.transport.write("UPDATE " + path + ";" + message + "\n")
 
# Factory
class Manager(Factory):
	def __init__(self):
		self.protocol = Comet
		self.comets = {}
		self.lookup = {}
		self.threadCount = 0
 
	def startFactory(self):
		pass
 
	def stopFactory(self):
		pass
 
	def register(self, path, comet):
		if path not in self.lookup:
			self.lookup[path] = set()
 
		self.lookup[path].add(comet)
 
	def deregister(self, path, comet):
		if path not in self.lookup:
			return
 
		if comet not in self.lookup[path]:
			return
 
		self.lookup[path].remove(comet)
 
		if len(self.lookup[path]) == 0:
			del self.lookup[path]
 
	def message(self, path, message):
		if path not in self.lookup:
			return
 
		for i in self.lookup[path]:
			i.sendMessage(path, message)
 
	def nextThreadNumber(self):
		self.threadCount = self.threadCount + 1
		return self.threadCount
 
def thread_start():
	global dolores_reactor
	factory = Manager()
	reactor.listenTCP(8007, factory)
	reactor.run(installSignalHandlers=0)
	print "Dolores has been taken by the Centaurs. Clip clop."
 
 
dolores_thread = None
def start():
	print "Starting Dolores..."
	global dolores_thread
	dolores_thread = threading.Thread(target=thread_start)
	dolores_thread.start()
	print "Dolores has  now been appointed High Inquisitor."
 
def stop_reactor():
	reactor.stop()
 
def stop():
	reactor.callFromThread(stop_reactor)
 
if __name__ == "__main__":
    start()
    run = True
    while run:
    	try:
    		time.sleep(5)
    	except KeyboardInterrupt:
    		stop()
    		run = False

And, the arguably even uglier Cornelius, with raw socket communication:

cornelius_connection = None
 
import socket
import time
import os, os.path
 
class CorneliusFault(Exception):
	def __init__(self, value):
		self.value = value
	def __str__(self):
		return repr(self.value)
 
 
def _connect(reconnect = False):
	global cornelius_connection
	if cornelius_connection and reconnect:
		try:
			cornelius_connection.shutdown()
		except:
			pass
		cornelius_connection = None
 
	if not cornelius_connection:
		cornelius_connection = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
		cornelius_connection.connect(("localhost", 8007))
		cornelius_connection.settimeout(1) # wait one second for response if needed. Hopefully won't be that long.
 
		buffer = read()
		if len(buffer) < 2:
			raise CorneliusFault("He's Not Back!")
 
		verify_dolores = buffer[0].strip()
		if verify_dolores.strip() != "I, Dolores, High Inquisitor, Hogwarts.":
			raise CorneliusFault("Lord Thingy! Lord Thingy! Dolores, why have you turned into Lord Thingy?")
 
		cornelius_thread_id = buffer[1].strip()
		f = open(os.path.dirname(os.path.abspath(__file__)) + "/threads/control-" + cornelius_thread_id, "w")
		f.write("you big dummy.")
		f.close()
		send("CONTROL\n\n", True)
		read()
 
def read():
	try:
		buffer = cornelius_connection.recv(4096)
		return buffer.split("\n")
	except:
		pass
 
def send(what, noconnect = False):
	if not noconnect:
		_connect()
	global cornelius_connection
	try:
		cornelius_connection.sendall(what + "\r\n")
	except:
		if not noconnect:
			_connect(True)
		cornelius_connection.sendall(what + "\r\n")
 
	try:
		read() # don't do anythin' with output yet. Just get rid of it... so it doesn't sit in some buffer
	except:
		pass
 
def update(path, message = ""):
	send("UPDATE " + path + "; " + message)
 
 
def connect(uid, path):
	send("CONNECT " + uid + " " + path)
 
def disconnect(uid, path):
	send("DISCONNECT " + uid + " " + path)
 
 
def crash(uid):
	send("CRASH " + uid)
 
def log():
	global cornelius_connection
	print cornelius_connection.read_very_eager()

Well, again, at least they work. And they are quite simple.