Clojurians Log v2

@bozhidar, re https://github.com/nrepl/nrepl/pull/135, think the keywordizing question might be more complex than first thought

Yeah, I just replied to you now.

It’s actually not that complex IMO, because we don’t really have to return the same structure of data for each transport - I’d rather return what’s optimal for the particular transport. Although in the beginning we obviously are going to return pretty similar things just because that’s the easiest things to do.

Down the road - we’ll see. Just being able to send an EDN request map and get an EDN response would be a big success, even if the maps themselves are somewhat weird. 🙂

Left a reply, but think we are missing each other a bit on the question

so might be easier to chat here?

@shen Sure. Had a busy afternoon, so I saw your message here just now.

Overall it seems to me that we are almost on the same page. 😄

Think so.

hey

If we are happy to release the EDN transport without committing to not making breaking changes, that makes it easier

Yeah, I totally am committed to this.

committed to not committing 🙂

Generally I don’t plan for us to make any breaking changes as far as bencode usage is concerned.

long term, exposing raw EDN transport and have everything work in a predictable manner, including third party middleware, is definitely gonna take some articulation of requirements

What I was talking about is that to fully leverage EDN, eventually we might want to change some aspects of the return values there, as currently much of the responses are dictated by the limited data types that exist in bencode. That’s certainly not a must-do, but probably the end users would appreciate it.

But definitely we should work in small steps and first just get to a point where people could use EDN.

so, I'd like to change the transport to be pretty transparent, except having some shimms in place to bridge the gap between how things work internally, and how we want them to work

I'm hoping it's going to be limited to :status and :op values being keywords

Yeah, that sounds reasonable.

I actually had forgotten those were keywords internally.

And you’ve noticed a fun mistake we’ve made with the manual - referring to all ops as keywords, even if there’s no way to invoke them like this if you’re not using the Clojure client.

think :op is actually all strings internally

but :status are keywords

so, this issue: https://github.com/nrepl/nrepl/blob/master/src/clojure/nrepl/transport.clj#L40

would it break the transit transport if we fixed it?

(that's fastlane, right?)

Depends on the request - if you send strings it should be ok. That’s something pretty easy to fix, though.

Yeah, that’s fastlane.

do we want to fix that now?

Well, that’s as good time as any. Generally that code is bencode-specific.

cool. will see what I can do

Thanks!

Things are shaping pretty good pretty fast! Thanks for tackling this and everything you’ve done recently! Much much appreciated!

only a pleasure