The number indicates the number of entries in the following message; and yes, you're right that a sentinel would have been sufficient to terminate each message, though I wasn't attempting to follow in other protocols' footsteps. I'm sure the protocol is lacking in a variety of ways; as I said, I'm no expert in that department. In the end though, it *seems* to be easy enough to implement a client for in various environments/languages (see my prior msg).
In any case, my objective with nREPL was to get something working well that had what I thought were the right semantics for the use cases I was concerned with (i.e. point-to-point Clojure tooling backends). Lifting those semantics onto other transports in the future shouldn't be difficult (I think Rich was pretty unhappy with the protocol as well -- IIRC, he would have preferred using STOMP directly, but it's important to some users of nREPL that external dependencies be minimal/nonexistent, and a Clojure STOMP broker has yet to come along). Is the protocol as-is a blocker for your attempt to build a SLIME client for nREPL? - Chas On Mar 20, 2011, at 5:39 PM, Kevin Downey wrote: > My objection has nothing to do with string vs. byte. > > Messages used in wire protocols exist on a continuum between fixed > width and variable width. The happy medium there, which almost all > protocols follow is a fixed width header that also provides the bye > count of the following variable width body. The nrepl protocol appears > to have aimed at that, but missed. > > Fixed width messages have the advantage of being extractable from the > byte stream without having to do any parsing, while with a variable > width message format you must parse and extract messages from the > stream in the same step. > > After trying to write a nrepl client it is fairly obvious to me that > in the creation of the protocol similar protocols were examined and > because they were prefixed by numbers, the nrepl messages were, > without a clear understanding of why and what the purpose of the > number is. As implemented the number may as well be replaced with some > kind of START and END tag. > > On Sunday, March 20, 2011, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: >> Yes, as a heavy Emacs/SLIME user who does not work with Common Lisp any >> more, I'd rather have a Clojure-specific Emacs environment, especially >> something that can do more introspection of the JVM, e.g., look up JavaDocs >> and examine classes through reflection. >> In my not-terribly-well-informed opinion, string-oriented protocols are >> easier to parse in string-oriented languages like Perl and Emacs Lisp, >> whereas byte-oriented protocols help avoid mixups with character encoding >> and line-endings. Pick your poison. >> -Stuart Sierraclojure.com >> >> >> >> -- >> 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 -- 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
