Slightly stuck

I freely admit I am probably over thinking the problem for the moment, but there is some doubts that maybe I am not. The problem is my concern of overloading Pymetheus with non-command & control messages, specifically low priority stuff like a chat scenario between user A & B. A types “Hey B, how’s it going?” which currently would need to descend down to a chat handler, run through some sort of sanitizer, then interface to auth.realm.UserRegistry to find the specific user, and then push a message to this person.

Its not really so bad to do this and in a lot of ways, it makes sense. All the information and constructs to accomplish the task is there, but it would need to be immediately refactor’d out at the first opportunity for one single reason: scalability. If Pymetheus suddenly starts taking on more and more trivial tasks, one day I am going to wake up and have this monolithic super process that does everything and has a memory profile similar to a swamp.

The ideal solution in my mind is:
User A & B connects and should be granted Chat privileges, accounts are created or activated on a xmmp server alongside pymetheus which returns connection credentials to Pymetheus which passes this back to each User. A & B now connect to the xmpp server and can chat away to their hearts content. Alongside some of the weirder xmmp sub-protocols this solves a whole slew of things that must be implemented ( presence, offline messaging, event notification, etc ).

A DRY abomination

One of my habits when presented with a new framework/platform is to implement a problem I know like the back of my hand. Usually the user interface isn’t of concern so I haven’t done much to improve on the logic there. I decided to try something different with this implementation of Tic-Tac-Toe:

Given the following

        <table border="1" style="height:100%; width:100%" >
            <tr class="x0">
                <td class="y0">&nbsp;</td>
                <td class="y1">&nbsp;</td>
                <td class="y2">&nbsp;</td>
            <tr class="x1">
                <td class="y0">&nbsp;</td>
                <td class="y1">&nbsp;</td>
                <td class="y2">&nbsp;</td>
            <tr class="x2">
                <td class="y0">&nbsp;</td>
                <td class="y1">&nbsp;</td>
                <td class="y2">&nbsp;</td>

I used the following logic to determine the coordinates from a user click

var clickHandler = function(e){
//Recieves a plan/jQuery managed event object                    
       var element =;
       var parent  = element.parentNode;                    
       var x,y;
       //Below is fine for 0-9 scenario's but will need to be refactored for more
       //advanced/larger grids.
            y = element.classNames().detect(function(cls) { if( /y\d/.match(cls)){ return true; }})[1];
            x = parent.classNames().detect(function(cls) { if( /x\d/.match(cls)){ return true;}})[1];
         console.log("Coordinate " + x + "," + y);

The cool thing about this, is that with jQuery I can do jQuery(“#myTable tr.x2 td.y0”) and get the exact cell I am looking for… or even crazier stuff like:
“#myTable td.y0” to select vertically down a row
“#myTable tr.x0” to select horizontally.

Adventures in Javascript dependancy loading

One of my most personally successful philosophy’s in dealing with Web browsers is never blindly trust them.

My initial solution to loading in dependencies depended on a switchboard style approach, if browser support onready or similar events then bind an anonymous function to make the appropriate notice.  Else spin up a interval based checker anonymous function that looked every few seconds for the script for about a minute.    This solution kind of worked, but not reliably because it depended on browser detection vs. capabilities detection.

Instead of reworking things to attempt to ferret out what capabilities a foreign browser supports, I went with a brute force approach that will eventually be a foundation for a much more advanced system.

So the prototype works like such.

wm.loader.load(“someModule”) which becomes the path “/mods/someModule.js” and that is applied to a new script tag as it’s src attribute.  This is then appended to the head tag.  All pretty standard stuff actually.  What’s different is the notification process.

someModule.js contains a simple line “wm.loader.notify(“someModule”) ” which hits an internal dictionary and if this is the first notification, fire’s of a notice to the server.

Simple and guaranteed to work reliably.   Plus it gives me room to grow for later.

Like adding a call like “wm.loader.multi(“lib1″,”lib2″,”lib3”, 10,  function(){   doSomethingWhen Dependancies met });

arguments[0-2] can be detected and pushed to a callstack array, any integer can be assumed to be a time out period, and the last argument as an anonymous function can be assumed to be a onSuccess callback.   A dependency failure mechanism could be incorporated into the actual loader lib as either an observable emitter or just a cry for help back to the service.

More involved:

wm.loader.multi( ){
          var dependancies = [],  timeOut = -1,  callBack = None;
          loop through arguments:
                    if( current instanceof string ){
                           append to dependancies
                    else if( current instanceof integer){
                             append to timeOut
                    else if( current instanceof function ){
                                assign to callBack
              var dependancyCheck = function(loadedLib){
                                          pop loadLib from dependancies;
                                         if dependancies.length <= 0 then
                                                     cancel timeOut 
                                                     call  callback;
    wm.loader.load, dependancyCheck );

I would be lying if I said I knew this construct would work perfectly once I implement it, but I think the general idea is something to work with.


So I am not much for talk right now so straight to the points:


I started Pymetheus originally to create a platform for a near real time web based multi-user dungeon… but I wasn’t satisfied with what was available as far as feature complete frameworks and toolsets.  I wanted to create a VERY rich web application that used as much of the newer possibilities being rolled out by HTML 5.  Specifically web sockets, local & session storage, and then branch out to using the Canvas tag and whatever else I could pull off.  So a normal bread & butter html

Change of plans:

I’ve had more rewarding of an experience making the platform then I have making the game.  Of course I can’t make the game until the platform is stable, but with few exceptions, when is a platform ever completely stable when it involves the internet?

Brief outline:

Client side is a rich web application that relies completely on dynamically injected/loaded content and logic to function.   On the initial load, there is nothing but a blank blue page and about half a dozen scripts src’d in.

From authentication, modules,  mini-app like bundles, are bootstrapped into the client by means of dynamically injecting new script tag’s with src links to corresponding logic.  If any of the modules depends on external content like images or extensive HTML markup, that logic is dynamically loaded in as well.

While all of this is happening, the service side is merely instantiating classes called handlers to provide the business logic and hold some of the more important parts of the module’s state.   One trick about these handlers is that they don’t have to belong to the platform but instead can come from any package available on the Python import path.    The closest comparable design to this would be a WSGI based application, where a WSGI app can include other WSGI apps according to the URL path.

Anyway, I have the platform up and running and the three parts I feel need to be hammered out some more are

  1. Working example of a Model system
  2. Cleanup the user management system, it’s functional but has some weak points in it’s design
  3. Implement a multiplexing message system that won’t encumber the platform, specifically for passing non-control messages between users.

Mission statement and introductions

This blog is dedicated specifically to the trials and tribulations of Pymetheus and what I learned/accomplished the along the way to it’s creation.  I won’t be going into much depth about the project with this post.

Otherwise, about me.  I began my trials with computers somewhere around the late 80’s with a Apple ||e personnel computer.  I wish I still had a copy of the first few scripts I wrote, but the more advanced of them was a simple alternating game loop structure.  In the initial state, the computer would randomly pick a number from 1-10 and the user had to guess it.  After 3 tries, the person would then pick a number in their head and the computer would pick 3 random numbers.   So input could be summarized in a regex like ( [0-9]{1}| [YyNn]{1}) and the whole deal was something I could do in a minute.  It’s kind of funny to think about because It took me a few days to get that working right.

After that, I didn’t do much programming but I did spend a considerable amount of time of trial and error time with computers, at one time landing myself a part time job at age 14-15 doing computer repair & support.   What got me back into the programming game was when i first played Quake’s demo and then later learned that you could modify the game logic api for free… you just had to learn c/c++.    So began a lovely adventure into the world of compiled strictly typed langues and pointers.   I actually miss that environment but its pretty rare for me to fire up gcc and build up binary exectuables

After that the rest of my life got kind of weird, i knew i wanted to be a professional programmer but a lot of things got in the way, the biggest one being the economy and the death of the web for a time.