I am no python programmer, but if you look at http://docs.python.org/library/socket.html you see it passes in the number of bytes you wish to receive on a call to the receiv method on a socket. With that in mind parsing nrepl messages becomes a huge pain. At no time when parsing a nrepl message do you know how many bytes you need. The messages start with a string representation of a number (variable width) and the rest of the message is some set of new delimited strings.
I thought you were just advocating for ditching slime because it's not clojure centric enough, how does python fit into this? On Sun, Mar 20, 2011 at 9:27 AM, Chas Emerick <cemer...@snowtide.com> wrote: > > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
