http://dev.clojure.org/jira This file is an XML representation of an issue en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/NREPL-11 tools.nrepl <p>In particular, no boxing of individual bytes or multiple en/decoding steps should be involved.</p> <p>This implies that:</p> <p>1. all string values should remain <tt>byte[]</tt> coming out of the bencode protocol support (which makes it more compliant with bencode anyway)<br/> 2. the string decoding should occur in the bencode transport impl<br/> 3. all string values should be decoded, <em>except</em> for those named in a reserved slot (say, <tt>"-unencoded"</tt>)</p> <p>All map keys should always be decoded to Strings.</p> <p>While nREPL should continue to be fully compatible with Clojure 1.2.x, let's not kill ourselves trying to optimize for 1.2.x as well as Clojure &gt;= 1.3.0; if necessary, just make sure the latter is fast. If 1.2.x benefits as well, then good.</p> NREPL-11

Ensure efficient bytestring (byte[]) support in bencode transport

Enhancement Major Closed Completed Chas Emerick Chas Emerick Tue, 21 Feb 2012 19:33:08 -0600 Tue, 21 Aug 2012 20:26:25 -0500 Tue, 21 Aug 2012 20:26:25 -0500 0.2.0-beta9 0 0 <p>How about “<tt>nrepl/unencoded</tt>” re point 3?</p> <p>Is that intended to become a namespaced keyword at some point (further up in the stack than the bencode parser or transport, of course)?</p> <p>If so, does that imply that other keys (perhaps "nonstandard" ones defined by middlewares) should be namespaced as well?</p> <p>Also, this is actually impacting the protocol; <tt>nrepl/*</tt> makes me think the slot is related to an "application-level" handler provided by nREPL.</p> <p>FWIW, my suggestion of <tt>-unencoded</tt> was a nod to Python's <tt>_foo</tt> and Clojure's <tt>-foo</tt> to denote private / internal members. &#42;shrug&#42;</p> <p>Namespaced keywords are indeed the inspiration. So that it should probably be more like <tt>clojure.tools.nrepl.transport/unencoded</tt> rather than just <tt>nrepl/unencoded</tt>. However it is not a requirement to be a real keyword. A qualified string works just as well. There could be a middleware which turns the map keys into keywords (considering also a possible namespace). ring has a similar middleware, IIRC. I think that qualified operation and result field values (in some form or the other) are a best practise in this respect.</p> <p>However your argument of <tt>unencoded</tt> being part of the protocol is valid. But then why should it be private? Document it in the official protocol spec and let middlewares also add fields to it. The question is then: what happens with nested structures (eg. <tt>:status</tt>, which has to be traversed now painfully)? If middlewares weren't allowed to add to it, then only <tt>:value</tt> would be an interesting target for <tt>unencoded</tt>. So a simple flag would suffice.</p> <p>In general, I still think a tagged protocol would have been the better solution since it also allows nesting and each slot knows whether it's encoded or not.</p> <p>Maybe we should clarify what middlewares are allowed to do. Is there already some documentation on this? (I'm must confess I'm not up-to-date with all the design changes.)</p> <p>Re: encoding, I've started to think perhaps nothing should be decoded by default, and middlewares can independently handle such things. The standard middlewares will stake out one approach, but that at least leaves open the possibility of a different convention emerging over time that can be adopted later.</p> <p>Opinions?</p> <p>Sorry, where is the code for this? No .patch here, and nothing in bitbucket looks right.</p> <p>Leaving aside the code for now, defaulting to unencoded strings continues to seem reasonable; a default <tt>Transport</tt> impl/substrate can perform the en/decoding, as well as establish a default convention for indicating that some fields values should be left unencoded and should not be decoded.</p> <p>The code is here: <a href="https://github.com/kotarak/tools.nrepl/tree/bencode-improvements2">https://github.com/kotarak/tools.nrepl/tree/bencode-improvements2</a></p> <p>Looks good, patch applied.</p> <p>I'm less and less sure re: <tt>-unencoded</tt>. Thinking back to your "tagged protocol" comment, adopting a convention of keys like <tt>"value/binary"</tt> (or something similar) would be quite a bit more flexible and somewhat simpler to handle.</p> <p>(Thinking of rich content, mime types could then be sent in e.g. <tt>"value/mime"</tt> — not that the transport would care about that, but it would at least be easy to pair up data with its "tag".)</p> <p>Thoughts?</p> <p>Releasing -beta9 now; further discussion of unencoded value semantics can continue elsewhere…</p> Global Rank