socketio
¶
This module holds the main hooking function for your framework of choice.
Call the socketio_manage function from a view in your framework and this will be the beginning of your Socket.IO journey.
- socketio.socketio_manage(environ, namespaces, request=None, error_handler=None, json_loads=None, json_dumps=None)[source]¶
Main SocketIO management function, call from within your Framework of choice’s view.
The
environ
variable is the WSGIenviron
. It is used to extract Socket object from the underlying server (as the ‘socketio’ key), and will be attached to both theSocket
andNamespace
objects.The
namespaces
parameter is a dictionary of the namespace string representation as key, and the BaseNamespace namespace class descendant as a value. The empty string (‘’) namespace is the global namespace. You can use Socket.GLOBAL_NS to be more explicit. So it would look like:namespaces={'': GlobalNamespace, '/chat': ChatNamespace}
The
request
object is not required, but will probably be useful to pass framework-specific things into your Socket and Namespace functions. It will simply be attached to the Socket and Namespace object (accessible throughself.request
in both cases), and it is not accessed in any case by thegevent-socketio
library.Pass in an
error_handler
if you want to override the default error_handler (which issocketio.virtsocket.default_error_handler()
. The callable you pass in should have the same signature as the default error handler.The
json_loads
andjson_dumps
are overrides for the defaultjson.loads
andjson.dumps
function calls. Override these at the top-most level here. This will affect all sockets created by this socketio manager, and all namespaces inside.This function will block the current “view” or “controller” in your framework to do the recv/send on the socket, and dispatch incoming messages to your namespaces.
This is a simple example using Pyramid:
def my_view(request): socketio_manage(request.environ, {'': GlobalNamespace}, request)
NOTE: You must understand that this function is going to be called only once per socket opening, even though you are using a long polling mechanism. The subsequent calls (for long polling) will be hooked directly at the server-level, to interact with the active
Socket
instance. This means you will not get access to the futurerequest
orenviron
objects. This is of particular importance regarding sessions (like Beaker). The session will be opened once at the opening of the Socket, and not closed until the socket is closed. You are responsible for opening and closing the cookie-based session yourself if you want to keep its data in sync with the rest of your GET/POST calls.