CLJC Port
colonelrascals opened this issue · 14 comments
Would a port to CLJC be the best solution for ClojureScript-compatibility?
Yeah, totally. That's the reason we extracted this library in the first place from nREPL - so that it can eventually to ported to cljc and it could be easier to write ClojureScript clients for the default transport.
This is great! I think I should be able to find some time to work on a port!
That would be much appreciated!
Just a note, the decoder should not operate on strings. It should operate on a stream of data, e.g. network data coming in chunks.
Too many bugs are caused by half-finished streams of data.
I'm just going to go ahead an ask the question.
Could we use messagepack as an alternative?
to expand:
Is there something about bencode that makes it preferable for nrepl as opposed to using MessagePack or even JSON as a data exchange format?
I suspect the answer is "yes" and it has something to do with "stream of data" like @SevereOverfl0w mentioned, but I am not entirely sure.
Apologies if this is a silly question. Just trying to understand the problem domain better :)
Is there something about bencode that makes it preferable for nrepl as opposed to using MessagePack or even JSON as a data exchange format?
nREPL is data format-agnostic. You can use whatever data format you want, provided you implement nREPL's transport API for it (see https://nrepl.xyz/nrepl/design/transports.html). The default transport is bencode, because we have to be very careful with the 3rd party deps we use in nREPL, as they might end up conflicting with some of your application's deps. That's also why this bencode library lived in nREPL itself for a very long time. There's also the fact that bencode is a very simple format, so pretty much any client can handle it relatively easy. That's not going to be the case for something like EDN or MessagePack. :-)
I hope this makes sense.
Btw, once we add the EDN transport nrepl/nrepl#67 this might become a mute topic. I assume ClojureScript clients would naturally prefer using EDN over bencode. //cc @PEZ
FWIW, I had a look and punted on this exactly because of edn support coming up. There are so many things relying on Java primitives that it is almost worth writing a new cljs-only lib or use a JavaScript lib.
I was eyeing this: https://github.com/themasch/node-bencode/blob/master/README.md
It does not look like it works out of streams but it processes buffers. Was thinking that I actually do not really like what the bencode lib does at the moment. It involves both host interop and "logic". Ideally there should be a layer taking care of the stream of data in and a lib just trying to translate the buffers - the latter being a set of very simple .cljc files.
I am so ready to say goodbye to Bencode! nrepl/nrepl#67 gives me hope.
OK, I guess we can safely close this then.
There's nothing nREPL-specific about this particular library. It was just extracted from nREPL so Clojure devs looking for a bencode library can use it. I guess @PEZ and @mauricioszabo can share here what's the bencode library they are using. In general bencode is so simple that I assume many clients just implement bencode internally.
@bbatsov, @sergeiudris gladly: https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/nrepl/bencode.cljs
If you need help on how to use it, just see the test: https://github.com/mauricioszabo/repl-tooling/blob/master/test/repl_tooling/nrepl/nrepl_test.cljs#L36-L69
The "encoder" is really simple: you send an EDN, it returns a bencode string. The "decoder" is a little bit harder, because it handles incomplete output - so, if you receive a stream of data, and that stream is not a full map or array, for example, it'll parse until it can, then "cache" the result and keep parsing when there's more info. There are performance tests commented on the code too, if you want to check 👍