On Mar 20, 2011, at 3:13 AM, Kevin Downey wrote: > nrepl's protocol is also very line reader centric, which is a drag, > and the "integer" that prefixes messages is really just a variable > length string and is not useful for allocating buffers to receive data > in a client because it is a lines / 2 instead of a byte count. this > makes writing a client that uses anything but a BufferedReader > challenging. I am not advocating the slime protocol, but at least the > slime protocol prefixes message with a fixed width representation of > the count of bytes in the rest of the message. > > I have been toying with a slime<->nrepl and using nio and polling to > make it all run in single thread, the slime protocol is very easy to > process like this, while I haven't been able to figure out a good way > to parse the nrepl protocol without having a thread continuously loop > around reading lines from the socket.
My apologies for not getting back to you privately about this earlier. It's been a hell of a week. When I was designing the protocol, my aim was to make it simple enough to implement from, e.g., Python, and able to be hoisted up onto something like STOMP with relative ease. Thus, line orientation and all-strings made a lot of sense. I would not pretend to be an expert at designing network protocols. My question would be: in what context is allocating response buffers efficiently a must-have? - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
