whyfore chat, with django, twisted and websockets?

Aside

upon seeing the work i’ve put into writing tutorials, showing how to get realtime chat working in django + twisted/websockets, you might make the assumption that i consider this architecture to be, in general, a good idea.

A.

twisted’s implementation of websockets is, as of this writing, not integrated into the main branch.

don’t use code that isn’t considered, by its authors, to be reliable enough to merge into and release as part of their application distribution.

B.

twisted is an event-driven networking engine
django is a solid, easy to use web framework
websockets, a tcp based protocol, is usually implemented as a strange mix between the tcp and http protocols

it is, generally speaking, not a good idea to mix abstraction levels; adding event-driven components to your application by combining twisted and django is a bad architectural decision. I strongly suggest you consider using twisted.web instead of mixing django and twisted.

websockets are a strange mix of protocols, and can be difficult to work with unless you are very careful with your choice of libraries and application design, scope and implementation. at the time of this post, i would recommend against using websockets, in production, with the standard deployment of twisted. i strongly urge you to consider the following alternatives, in rough order of likelihood to work for you:

 


null vs. undefined (javascript)

Aside

how well do you know your “null”s and “undefined”s?

write down what you expect the result of each operation to be. run them in a javascript console (ChromeFirefox/FirebugSafari). compare, verify, contrast, and, for fun, give yourself a score out of “3/4 donut”.

// Equality
null == undefined
null === undefined
!null == !undefined
!null === !undefined

// addition and concatenation
null + ''
undefined + ''
null + 1
undefined + 1

// fun with enumerations
test = []; test.push(null); console.log(test)
test = []; test.push(undefined); console.log(test)
{null:2}
{undefined:2}
{a:null}
{a:undefined}

[More programming riddles]

wtf javascript

Aside

javascript riddle time.

say that you’ve ventured into the land of XmlHTTPRequest ( $.ajax calls for the jquery people), and you’ve heard through the grapevine that (gasp!) it may be possible to make cross-domain http calls with this tool.

excitement! if you’re like me, you’ll see a chance to hack in fixes for a myriad of small bits of javascript you have lying around. so, off you’ll go, merrily trying anything that might work – your initial code might even look something like this, if you’re used to jquery:

  request = $.ajax({
        type: "POST", // !? - request sent through as HTTP GET
        url: 'http://someotherdomain.com/,
        data: 'some data',
        async: true,
        cache: false,
        dataType: 'jsonp',
        crossDomain: true,
        xhrFields: {
	       withCredentials: true //share cookies across domains!
	},
  });
  request.abort(); // !? - does nothing

confused


ok, so, technically this is a wtf jquery, more so than a wtf javascript. ‘jsonp’ crossdomain requests aren’t currently supported, natively, by most browsers – a native implementation would take significant care to avoid being a security risk (i’m not entirely sure it’s possible, even). there is, though, a fairly generic hack for implementing them. take a look at jquery-jsonp, which is close to the state of the art of what’s possible nowadays, and you’ll even see it there:

  // Create the script tag
  script = $( STR_SCRIPT_TAG )[ 0 ];
  script.id = STR_JQUERY_JSONP + count++;
  
  ...

  // Set source
  script.src = url;

create a new script tag, with the source set to be the target of your jsonp request, dynamically add it to the document tree, and wrap it in event handlers to handle the response or any errors.

since it’s a html script tag, it always leads to a browser HTTP GET request; and, since the request is initiated indirectly, by adding the tag to the document tree, some of the usual niceties for XmlHTTPRequest aren’t available – eg, the ability to interrupt.

mystery demystified – the behaviour is correct, though still unpleasantly surprising to me


[More programming riddles]