Clojurians Log v2

tried checking describe op but found nothing

As in, how to know on the server side what type of client has connected to it?

I'd expect that client send any info in any op to know that, similar to the LSP protocol initialize request

Looking at the docs and the code, I don't see any standard way for clients to identify themselves. There is no init op, a successful socket connection means that the client is active and is allowed to send requests.

yeah, that's what I was afraid 😔

Do you want to tune responses based on the client?

nope, I'm building a middleware that will export multiple metrics about the REPL usage, since JVM startup to evaluated things and errors. One of the metrics I want to export is the client used

I just found that I think I can wrap describe middleware and access the :aux , so maybe infer something from there:

{:id "3",
 :session "98b13ffd-efc3-4450-8a52-25b16af0a61e",
 :aux
 {:cider-version
  {:major 0,
   :minor 52,
   :incremental 0,
   :qualifier nil,
   :version-string "0.52.0"},
  :current-ns "user"},
 :ops
 {...},
 :versions
 {:nrepl {:major 1, :minor 3, :incremental 1, :version-string "1.3.1"},
  :clojure
  {:major 1, :minor 12, :incremental 0, :version-string "1.12.0"},
  :java {:major 17, :version-string "17.0.13"}},
 :status #{:done}}

hum, although that cider is related to cider-nrepl and not cider from emacs I guess

Yeah, 0.52.0 is a cider-nrepl version (the middleware library)

that's a pity there is no info like that on any op request or response

Yeah, seems like that

does it sounds like a crazy idea to add to a describe op something like :client-name "my-plugin", :client-version "..." to cider, calva, and clojure-repl-intellij? I believe only cursive is not easy to add, but most of main editors yes, if maintainers agree. Not sure there is a better idea

The client is not required to call describe, that's the thing

yeah I know, but I think all of the main editors do that

Looking at CIDER, it indeed invokes describe at the beginning to get server capabilities.

it's just really weird to me I can't know what client initialized the nrepl process

feels like nrepl should have a built-in op or something to help with that

Again, it's not about having op, but about obliging the clients to call it. That is a change in the protocol.

I don't mind sending client identification in describe, although it feels a bit hacky

yeah, I agree we cant obligate that, but more like a good practice

> although it feels a bit hacky agree

@bozhidar can probably tell better if it's a viable approach

> does it sounds like a crazy idea to add to a describe op something like :client-name "my-plugin", :client-version "..." to cider, calva, and clojure-repl-intellij? I believe only cursive is not easy to add, but most of main editors yes, if maintainers agree. Any op can contribute to the describe - this was part of the idea, so we can get richer information about the server's environment. I'm not sure if that's the best course of action for you, but it's one option for you. Alternatively we can modify clone to accept some additional data I guess. So far there was never need to track the clients.

It's slightly different – it is not about describe op returning more data about the server, but about it accepting more data from the client (client details). Then there's the question what to do with that data coming in. Should nREPL save it somewhere?

Yeah, I get the point, that's why I thought it's best to add such info at session creation time (`clone`) instead of when the session gets described.

Interesting, so in your idea, client would send more data to clone which we could have a middleware that wraps clone and add such info in the session or as other fields?

Yeah, this seems like the most natural approach to me if you want to attach more info a session.

Ok, I'm open to open Prs in Calva, cider and Intellij that I know the codebase to add that info to clone, but I think we would need to open a new one to nrepl, adding that middleware, is that right?

something like that makes sense?

(defun nrepl-sync-request:clone (connection &optional tooling)
  (nrepl-send-sync-request `("op" "clone"
                             "client-name" "CIDER"
                             "client-version" ,cider-version)
                           connection
                           nil tooling))

on a second thought, I think only changing clients to include that info is enough for me, not sure we need that change on nrepl, just my middleware will use that wrapping that op

well we will need to change nrepl docs to include these optional client- fields, but I think only that?

Sounds good to me.

reviewplease https://github.com/clojure-emacs/cider/pull/3806

working on nrepl PR

reviewplease https://github.com/nrepl/nrepl/pull/370

maybe this can be called user-agent which is an already known mechanism from browsers/http-servers?

both work for me

But why? We never use the term agent anywhere

yeah, the nREPL client term is used usually to identify editors, I think so

yeah, I mean, on one side it is easy to infer for most people what it is about. On the downside maybe a user-agent is a string with some constrained format, I don't remember

https://github.com/BetterThanTomorrow/calva/pull/2774 waiting for nrepl PR

https://github.com/afucher/clojure-repl-intellij/pull/152 waiting for nrepl PR

https://github.com/Olical/conjure/pull/659 waiting for nrepl PR

I think only cursive missing from plugins of main editors, I can talk with colin later after those others are merged

you stole my thunder with that conjure pr lmao. i asked in the discord about finding the version earlier.

Other nrepl params use kebab-case, is there a point with keeping it like that also for these infos? (The PR uses camelCase, so that’s why I am asking.)

Also wondering is sending along editor, os, and cpu architecture may make sense.

@pez I thought calva would convert camelCase to kebab 😅 , so maybe we need to make that on calva side as all nrepl params are kebab, right?

About the other data, the server can access that via properties, only editor that not, but we can discuss if it makes sense to send the editor, because indeed Calva is not enough to know if it's being used in VSCode or Cursor, for example

Yeah, lot’s of forks ! 😃

There is no auto-conversion of camel to kebab happening.

Just fixed the calva PR!