Metadata-Version: 1.0
Name: wsrpc
Version: 0.0.2
Summary: UNKNOWN
Home-page: UNKNOWN
Author: Brett Graham
Author-email: braingram720@gmail.com
License: UNKNOWN
Description: By default this will try to use tornado
        
        To use gevent, set the environment variable: WSRPC_USE_GEVENT
        
        
        
        Make a web interface to a pizco served object (possibly many objects?)
        
        Browser <-> pizco communication is handled by flask-sockets (websocket)
        
        For my purposes I need support for:
        - setting config (dictionary)
        - checking when config is updated (signal?)
        - calling member functions
        - support for concurrent.futures
        
        Additional things to add would be:
        - support for general 'remote objects'
        - support for non-standard json objects
        
        This interface should support use of knockout.js observables so that:
        
        web ui change <-> javascript variable <-> websocket <-> flask <-> pizco
        
        
        An alternative is to 'ajaxify' objects directly. Making the pipeline:
        
        web ui <-> js <-> ajax <-> flask <-> object
        
        This limits connections to web protocols. Pizco is more direct.
        
        
        Data values (numbers, strings, arrays, etc) should be mapped as follows:
        
        ko.observable <-> hooks to websocket <-> flask <-> pizco
        
        Functions should be mapped as follows:
        
        wrapped js function <-> websocket <-> flask <-> pizco
        
        Objects should be mapped with ko.mapping
        
        object of ko.observables <-> hooks to websocket <-> flask <-> pizco
        
        
        As a starting point, lets handle a simple ionode that supports:
        
        1) config setting/getting [this is all through configure]
        2) configure calling
        3) function returning future calling
        
        
        this needs:
        1) mapped observable and signal handling for config
        2) remote object for function
        3) same as #2 and future support
        
        use json rpc on top of websocket protocol
        
        client     ---- server
               startup
        connect     ->
        inspect     -> example proxy object
        js object   <- return proxy object properties, functions, etc
        
               functions
        call method -> call proxy method in greenlet
        result      <- return result, join greenlet
        
               signals
        reg signal  -> register for signal in greenlet
        process     <- process changed event
        process     <- process changed event
                 many ...
        
        if an object is blocking (say camera) Is it ok to just continue to block?
        I think so, this makes websocket timeout? (seems to be ok with longer polling)
        Perhaps futures could be handled differently
        
Platform: UNKNOWN
