Explore decoupling mechanisms

[bollwyvl]

The current work uses a mix of procedural, synchronous design, event handlers, asynchronous callbacks. jquery, underscore, d3. Buh.

this design is hard to track and understand, and would benefit from a more consistent structure.

postman

a message bus architecture. Basically, everything would accept a named message, like a url, and any number of arguments.

advantages

3rd party API-independence, as the scope of each message would be a single ticket, pull or repo, with the posted content being some json rdf.

streamer

sort of a generator thing.

example usage with Github API.

[bollwyvl]

Hm, postman was looking great, but i stumbled back on machina.js (a javascript finite state machine (FSM)) which uses postal.js.

One of the examples called out for machina is:

Offline vs Online: If your web application needs to support the ability to work offline,
then you could use an FSM to abstract how (and where) data is stored given the
two possible states.

This sounds really attractive. Further, postal also supports wildcard topics ne messages:

var starChannel = postal.channel( { channel: "Doctor.Who", topic: "DrWho.#.Changed" } ),
    starSubscription = starChannel.subscribe( function( data ) {
        $( '<li>' + data.type + " Changed: " + data.value + '</li>' ).appendTo( "#example3" );
    });

Which wil match all of these:

starChannel.publish( { topic: "DrWho.NinthDoctor.Companion.Changed", data: { type: "Name", value:"Rose"   } } );
starChannel.publish( { topic: "DrWho.TenthDoctor.Companion.Changed", data: { type: "Name", value:"Martha" } } );
starChannel.publish( { topic: "DrWho.Eleventh.Companion.Changed",    data: { type: "Name", value:"Amy"    } } );
starChannel.publish( { topic: "DrWho.Location.Changed",              data: { type: "Location", value: "The Library" } } );
starChannel.publish( { topic: "TheMaster.DrumBeat.Changed",          data: { type: "DrumBeat", value: "This won't trigger any subscriptions" } } );
starChannel.publish( { topic: "Changed",                             data: { type: "Useless", value: "This won't trigger any subscriptions either" } } );

Which sounds like something that can easily be gotten behind.

Now, the FSM might be overkill for what is needed, but postal looks like it has the right features...

[bollwyvl]

There is also SCION, which allows for validatable use of hierarchical finite state machines (HFSM)... however, would this be appropriate to a modular system? perhaps using postal inside the state machine would allow the über states to be modeled, with the individual handlers "doing what they do". If auctions were used for providing data, this might be key, as that state situation would be messy with pure callbacks.

[bollwyvl]

Also, async.js, mentioned over in #5. async.auto is particularly impressive.

Using async in a modular fashion would require some equivalent of registration magic to work. Rather than namespaced messages, and would basically end up looking like postman/postal, except mostly rewritten for our stuff... not sure if this is positive.

Not sure if the message bus architecture, or FSMs, would be ideally suited to this coding style, however attractive it may be.