-send and -send-async are separate methods so they can be in separate protocols. This allows you to check using satisfies? whether or not a socket supports async behaviour, without relying on catching an exception. There is not a -ping-async and -pong-async because this wasn't supported by the Jakarta Servlet websocket implementation. So we can't assume that if an underlying websocket library supports async messages, that it also supports async ping/pong. However, I could add a new AsyncPingPongSocket protocol to support it.

nice, thanks for the reply

other question, do you have plans to continue working on ring-2.0? I mean, we are already using ring-2.0 based protocols for some time now...

Ring 2.0 proved to be too much at once, but a lot of the ideas of Ring 2.0 are still sound. The approach I'm taking now is to implement the functionality of Ring 2.0 in a more piecemeal fashion.

So for example websockets will come in Ring 1.11.

When you say "Ring 2.0 protocols", do you mean the protocols for request/response maps?

yep

That could be a good next step for Ring 1.12 or 1.13.

FYI, we are using our internal adapter using undertow, that is right now ring2.0 based, but I'm working right now on integrate the new websocket ring protocol (instead to have our own) and we have a plan to parametrice the adapter to work with ring1 or ring2 based requests/responses

for now the approach for ring2, I have copied/impoted the ring.request and ring.response from ring 2.0 branch to our repo

until that namespaces are fully available on stable ring release

One of the difficulties I ran into with Ring2 was the need to support both Ring1 and Ring2 request/response maps. That is, not necessarily the protocols, but the different keys (like :status vs :ring.request/status). In retrospect, I'm unsure if this was a good idea.

Indeed, It is a breaking change, of course, But from my point of view is a good fresh view, and allows develop more efficient adapters, that perform less operations if final user does not uses some stuff from request...

the obvious problem is backward compatibility...

Well, the idea was that it wouldn't be a breaking change.

And therein was the difficulty.

and supporting middlewares that should work in both modes

From my own experience, developing the adaprter thatwe are already using in production for some time, making an adapter that works in both modes is not difficult task

Yes, it was more the infrastructure around it that I found to be difficult.

the difficult task is have the middleware work correctly

Right

but in this case, I think it is not bad approach on the library developers and builitin middlewares is to detect which kind of request or response is coming

I don't think I'll attempt tackling the new keys immediately, at least not in 1.12 or 1.13. However, I don't believe there would be a problem with adding protocols for potentially faster access of request/response data. The adapter would still need to return something that Clojure recognizes as a map for compatibility, but using the protocols could be faster than using keyword lookup.

that makes sense for me