A couple of loose ideas

[jlouis]

Here is a list of things you can do in the code base I saw after skimming through it.

• The session gen_server process stores SessionIDs in an ETS table. This mapping of Id to Pid is quite common in Erlang, so there is a project, esl/gproc@master , which does exactly that.
• You can easily avoid the need to trap exits in the session code. gproc will set a monitor on your process and clean up if your process terminates.
• Sending back go to a process when it enqueues is a bit dangerous. Other processes might send go back. Consider some unique reference with the call make_ref/0 and send that along, so it is safe. Perhaps you can write all of it via a gen_server:call/3 and then use gen_server:reply/2 if the reply has to be sent asynchronously.
• There are a number of calls to iolist_to_binary/1 in the code. If possible, consider sending iolist() constructions around instead. Many output functions takes iolist()s. Converting them to binaries means that you traverse the iolist() and copy its data to a new binary you form on the fly. This copying may be unnecessary, takes time, and it increases the pressure on the binary-allocator in the Erlang VM.
• Considered using another web server in the backend? Misultin is rather cool, but there are other projects, like klacke/yaws@master or extend/cowboy@master .. Since you already did a large part of the nasty work, and since the code has neat separation, this should definitly be considered. You may also be interested in talking to @omarkj who has shown some interest in SockJS for Cowboy.
• Considered using rebar to build the source code? To be honest, I've already converted part of the repository to rebar. With rebar, you can easily embed the project in other projects. I imagine this is the main intention of the code.

Finally:

• How do you stress test the code?
• I've tried to read the SockJS spec, but it looks like there are some prerequisites I don't understand, because there are a lot of parts in the spec I can't wrap my head around. There is a framing system, where we prefix messages for instance, but there is no description of why we want exactly these frames, what a frame is, what the grammar for frames is and so on.

[simonmacmullen]

jlouis: first of all, thanks for your interest!

1), 2) I'm a bit reluctant to bring in another dependency for that; I tend to like to keep dependencies minimal.

3. The process that receives 'go' is an HTTP request handler - there's no guarantee that's the same process that invoked send/2. It quite often will be but I don't want it to be mandatory. I'm not sure I understand your point that other processes could send 'go' - I mean yes they could but I always assume that if you're in the VM and able to send messages then you can do malicious things anyway.

4. I couldn't get Misultin to be happy with iolists. Maybe I need to try harder.

5. Yes, absolutely. Misultin was just the first server to come to hand. Cowboy is obvious. I'm currently trying to decide whether to support Mochiweb given that it doesn't really have WS support. I hadn't thought about Yaws but once it's abstracted it should be easy right?

6. Yes, we'll look at rebar. Just my ignorance and not wanting to spend the beginning of a new project learning a new build system.

7. So far we haven't. Yup, another TODO.

8. Yes, we're aware the spec is rather raw. Marek is going to look at improving it.

[majek]

I've tried to read the SockJS spec, but it looks like there are some prerequisites I don't understand, because there are a lot of parts in the spec I can't wrap my head around. There is a framing system, where we prefix messages for instance, but there is no description of why we want exactly these frames, what a frame is, what the grammar for frames is and so on.

This is a very good point. The sockjs-protocol is by no means done, and it's not yet clear (in my head) how much it should explain and how much just focus on testing. Feedback welcome!

I've added some prose about framing: sockjs/sockjs-protocol@77959f4

Shout if there's something more missing. I think that the prose should explain general ideas, and not focus on details, but that's open for a discussion.

[majek]

Considered using rebar to build the source code? To be honest, I've already converted part of the repository to rebar. With rebar, you can easily embed the project in other projects. I imagine this is the main intention of the code.

Added a bug for that #4

[majek]

I think we've answered all the points. Closing. Shout if I missed anything.

[majek]

How do you stress test the code?

There will be a simple stress test as a part of protocol definition:

• Smoke test sockjs-protocol#4