olsonjeffery / zzz-old-sugs Goto Github PK

network connection between two points.. should be abstracted away as much as possible from the js perspective .. need to support tcp and udp.. should probably just have one thread for all connections, for now (which means non-blocking sockets...)

.. i imagine it being something like..

1. a MessageProxyWorker that encapsulates all remote communications that registers with the MessageExchange.
2. the MessageProxy registers with a local MessageExchange the connections of remote agents.. so messages that should travel remotely will get handled by the MessageExchange and sent abroad...
3. any connection between two sugs processes should probably include a TCP socket between the two, as well binding to UDP ports on both ends (but what about a NAT'd client?.. worry about that later?) .. should a determination to send the message across-the-wire w/ TCP or UDP be made on the subscribe or publish side? .. how does subscription/delivery info propagate?

.. mostly need to figure out a sane impl for handling the network side of things.. also want to abstract out the SFML impl.. threading and networking is nice.. but i want to run it headless on a system w/o graphics ..

instead of polluting the global object with a bunch of helper funcs to call down.. push it into a single object..

where do global helper funcs impl'd in js go? should they all be a part of $?

push all of the JS code into an isolated class/cmd pattern type setup where we can spin up a new js environment with an arbitrary set of scripts to populate the env and then enter an event loop in the compartment..

the idea being that the multiple environments can be spun up, one per thread, with one (presumably on the main thread) handling the UI and IO from the player, with the backend running independantly on another thread and they pass messages via JSON (so no objects leaking between them, ie security by isolation).. networking would be a third thread but probably won't require a compartment, since it'll just be routing messages to/from the other two threads.. yeah.

impl:

introduce the concept of the Worker, which encapsulates a JSContext* and a global obj (so it's a js sandbox).. so far we have three specialized Worker types:

• a FrontendWorker which encapsulates SFML and will be called in an event loop on the main thread. With this in mind, there is, most likely, only one FrontendWorker per process.. a FrontendWorker wouldn't exist if we were running a "headless" build/configuration (ie dedicated server)
• a BackendWorker, of which there can be an arbitrary number.. these can be spun up and put in a separate thread and ran in an event loop
• a ConfiguratorWorker, which is spun up and destroyed during startup in order to fetch our config (stored in js) and load the moduleConfig (which tells us where to find the scripts that'll live inside of each Frontend/Backend worker)

...

Since these Workers are now isolated, we need to push the messaging system down into native code and provide a means for them to send messages back and forth.

• replace load()/loadNoPrefix() with require() that takes a path/module (adding js/coffee suffix optional).. and the loader will do logic to add .js/.coffee and do a __native_fileExists() check until it finds a match then pass that path into the native engine to load..
• scripts will return an object (via the coffeescript safety function or a DIY safety function in .js code) as the last expression statement.. that object will be what gets cached/returned by a call to require()
• all scripts require()'d in this fashion will be have their return value "cached" on a per-worker basis, so subsequent calls to the same (resolved) script path will result in the cached exports object being returned
• add a set of standard search paths for require() to use when trying to resolve a script location.. defaults should include the moduleDir (provided in the config), as well as the location of sugs-root/jslib (relative to the cwd of the running process) .. only do searches for scripts in these directories (this is the paths array passed in as part of config.js

I guess something rspec-like. sigh. dunno how I feel about nested contexts.

provide a CLI switch to run in "test mode".. so we can do something like

1. scan a single script and execute all of the scripts that load and run those tests..
2. scan a directory and load all of the scripts and run them as tests
3. blah blah etc

and some code

{when, before, after, it} = $.require "spec"

when "doing something fascinating" ->
  result = 0
  before ->
    result = sut.gimmeFourtyTwo()

  it "should have an interesting result" ->
    result.shouldEqual 42

note, in the above example, monkey patching system primitives (number, string, etc) is implied... how/what this includes will be a world of fun to work through.

http://stackoverflow.com/questions/2627004/embedding-binary-blobs-using-gcc-mingw

is probably a good place to start.. want to have a "release" build that embeds all of the scripts (the "sugs stdlib" consisting of underscore, cs and the sugs scripts) as binary resources which are loaded, as needed, at startup time..

this should happen post-$.require() (gh-1) and should work transparently from a user code perspective, with the only difference being that their scripts are packaged as binary resources instead of being read from the file system...

use uglify.js for script minification, as well?
https://github.com/mishoo/UglifyJS

off the top of my head:

• use of c++ bool vs SpiderMonkey JSBool .. probably should standardize on the former
• shift away from char* towards std::string where possible...
• consistent indentation/whitespace/bracketing
• consistent naming in c-code (to match c++):
  • camelCase (lose the box_car)
  • prefix native functions being added to JS code with __native_
  • function specs appended w/ FunctionSpec
  • JSClass's appended w/ ClassDef
• namespaces