ws::client-handler-data

[mishoo]

The :documentation bit on this slot implies that I can store whatever I need into it, but the fact it's not exported makes me a bit nervous. Am I using it properly? Shouldn't it be in the exports?

A little suggestion for improvement would be to provide an option — like hunchensocket — to name the class to be instantiated for clients. That'd be a client-class slot on the ws-resource class, which is exported and we're encouraged to inherit from it. That would allow users to add whatever slots they need. I'd be happy to work on it and send a PR if it stands chances to be approved.

Just for the record, one thing I tried was to use (change-class client 'my-own-class) in my specialization of ws:resource-client-connected. That works nicely, about 80% of the time :-) But randomly it'll lead to a "invalid frame header" error. That's likely a bug in SBCL; I'd report it, but I didn't yet manage to break it down to a simple test case...

[3b]

Yeah, it does look like client-handler-data should be exported.

I'm not sure if things are created in the right order for the resource to specify the client class, but it seems like a reasonable thing to do if it does work.

I suspect the problem with change-class in resource-client-connected is threading, possibly it would work better from resource-accept-connection? Not sure if it is a good idea or not either way.

PR for either option would probably be accepted, mostly just depends on how long it takes me to figure out what the patch is doing (or the original code for that matter).

[erjoalgo]

Following up on this thread. Is this the recommended way of associating client-specific metadata?