Pre-release
This release is a pre-release and may not be stable for production use.
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
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
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
wsrpc-dev.tar.gz
(10.1 kB
view details)
File details
Details for the file wsrpc-dev.tar.gz.
File metadata
- Download URL: wsrpc-dev.tar.gz
- Upload date:
- Size: 10.1 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
96f49f5894e0bb8acc5a1597e54cd5dd1ab744a1b636298f3ba23c3973bd5c10
|
|
| MD5 |
d56d071a3b1592053444959edc5d52e5
|
|
| BLAKE2b-256 |
645faf1f78026ef7db74d54f97f116766657a240d212020deb5b14d4f80ad47e
|