cgmartin/clj-wamp

WebSocket Application Messaging Protocol (WAMP) for Clojure and HTTP Kit

clj-wamp's Issues

Do subprotocol validation during handshake

See http://tools.ietf.org/html/rfc6455#section-1.3

Additional header fields are used to select options in the WebSocket
Protocol.  Typical options available in this version are the
subprotocol selector (|Sec-WebSocket-Protocol|), list of extensions
support by the client (|Sec-WebSocket-Extensions|), |Origin| header
field, etc.  The |Sec-WebSocket-Protocol| request-header field can be
used to indicate what subprotocols (application-level protocols
layered over the WebSocket Protocol) are acceptable to the client.
The server selects one or none of the acceptable protocols and echoes
that value in its handshake to indicate that it has selected that
protocol.

Sec-WebSocket-Protocol: chat

Exception is thrown when client sends non-JSON to server

Improve the error handling in on-message.

Allow custom function for generating the client session id

Currently the add-client fn generates a client session id from time and an incremented id. Allow this session id generation function to be customized. ie. pull id from a centralized data store when scaling horizontally.

Change `clients` and `topics` atoms to transactional refs

http://clojure.org/refs#Refs%20and%20Transactions
http://blakesmith.me/2012/05/25/understanding-clojure-concurrency-part-2.html

Allow multiple WAMP servers to be run concurrently.

I'm working on integration testing a combination Clojure/ClojureScript application that uses clj-wamp. The server side would be started within normal test environment and the ClojureScript side would run inside a phantomjs environment. I wanted some way to control actions within the phantomjs environment and I thought using a separate WAMP server to communicate with the running phantomjs instance would work. I don't think the current server implementation will allow multiple instances since it defines some top level refs in vars. My whole reason for wanting multiple concurrent servers might be a really bad idea but it still points to way the library could be improved.

Stuart Sierra had a recent blog post and a talk at Clojure West called Clojure in the Large that talked about some better approaches for handling state in applications and libraries. The short version is that libraries should avoid putting things in vars and instead just return a context object that holds the state and pass that back into library functions. The clj-wamp server code could probably be refactored pretty easily to put the refs inside a map or record and returned as a "server" context object. Functions that send events etc. would take this context object as an argument. The normal use case for clj-wamp could be to just stick the server object in a var and pass it back in. It would still be easy for users of the library but allow more flexibility in how it's used.

WAMP v2 support

My understanding is that WAMP RPC supports not only array params but also keyval params, passed at the same time during an RPC call. It looks like only array params are supported, but will keyvals be supported in the future?

I'm new to WAMP, so my apologies in advance if I have a fundamental misunderstanding of how the protocol (or this library) works.

Thanks!
--Alex

WAMP challenge-response auth protocol support

Implement in-band authentication.

See AutobahnJS docs for more info.

https://github.com/tavendo/AutobahnPython/tree/master/examples/wamp/authentication

WAMP-CRA permissions: Allow keyword ":all" for convenience

Explicitly whitelisting all of the RPC/Pub/Sub topics in the CRA permissions map can be somewhat tedious.

Allow the map to contain a shorthand :all keyword:

{:all true}
;; or mix/match per type, using a boolean
{:rpc       true   ; all rpc calls are allowed
 :subscribe false  ; no subscriptions allowed
 :publish   {("http://chat") true}} ; one topic allowed for publish

Allow dynamically defining RPC endpoints and event channels.

Great library though there's areas where I would like some increased flexibility. It doesn't appear that RPC endpoints or event channels can be dynamically added. Is there anyway this functionality could be added? If there's already a way to do this could you indicate how this could be accomplished?

Integration with other Clojure async http servers

Integrate clj-wamp with Aleph?

RPC with status updates?

Bit of a question, actually.

I have a service that handles long running tasks with progress reporting. Currently this works as follows: a user submits a task through POST which immediately returns a reply (in JSON) which includes a link to a web sockets url where the user can listen for updates (out of band). When the task is done the results are simply merged in with the status and pushed as a (last) status update. The client checks the JSON for the status and resolves a results future if there are results (or rejects if the task failed).

I'm looking to simplify this a bit and WAMP seems nice, however there does not seem to be an obvious way to send status updates for an RPC. Now I could just swap out the POST for a WS RPC (so that it returns a link to the status updates immediately) but it seems less than ideal. What would be your take on this?

ClojureScript WAMP client

Port AutobahnJS to ClojureScript