Pondering: 1/ should we worry about concurrent server implementations extension interop for the same platform? (forks) 2/ should we worry about extension interop between server impl for different platforms? (cljs, cljs, cljsjs, cljr...)

Imho we need to start from somewhere, so I'd start from 1, still keeping 2 in the back of our head

edited my questions, do you maintain your position?

mine is “forget 1 and keep 2 in mind”

put it this way, 1 seems to be a subcase of 2 (if done correctly)

(if I understand correctly of course)

I didn’t considered it but yes

in cloiure it’s easy to start an extended repl by calling clojure.main/repl, why not follow this lead?

I like the idea, yes, but also you don't want to call a function for everything you want to add to it...

the big cons to the clojure approach is that you don’t have access to the current extensions (eg if you just want to modifiy prompt), so it calls for some dynamic env

so for completion you should not need a compliment.core/repl function

what do you mean by > call a function for everything you want to add to it

But I think there is going to be a clojure.cljs/repl

what about (unrepl.repl/repl :action {:complete ...})?

yes, so nRepl has descriptors, that would resemble it

I declare which actions the repl would understand

the map would be merged with current one

extensions could then occur on the fly

yep I like the idea, I think that part of nRepl was actually good, I guess you are more than familiar with it 😄

no or if I got involved I suffer from post-coding amnesia

lol: https://github.com/clojure/tools.nrepl#middleware-descriptors-and-nrepl-server-configuration

or (alter-var-root! unrepl.repl/*actions* into {:complete ...})

the latter is more dynamic, why not an atom?

middleware deps hell

because we want to keep it local to the session?

yeah the problem of namespace munging comes back

on the jvm we can go nuclear and spawns a separate clojure in its own classloader

(not good for latency, hey boooot!)

lol yes, pods in boot are superslow

(to bootstrap I mean)

I thought we get to blame clojure for it being slow? 😉

well if Clojure is slow than Clojure in Clojure (pods) what is it 🙂 ?

@cgrand https://docs.google.com/document/d/1dnb1ONTpK9ttO5W4thxiXkU5Ki89gK62anRqKEK4YZI/edit?authkey=CMuszuMI you've been named as involved. It's too late now.

that’s why I never answer Chas emails anymore 😉

and I would rather blame clojure for making namespaces a mutability hell (Zach Tellmann has some name for that “clojure nasty mutability closet” or something)

so in the above, what is the content of the :complete key? a simbol that points to the completion function?

munging: let’s assume we live in a hickeyic world where libs only ever accrete features?

yes I liked the merkle tree for namespaces 😉

maybe obvious here, I assume the client will not know about that

:complete would map to a message template

oh ok cool

so it doesn’t say a thing about how namespaces are loaded. (the dreaded namespace talk)

yeah well, at some point the munged namespace needs to go back to the client

Which munged namespace?

or a mapping is done server side

say the munged compliment.core

server and client need to sync, either they speak unmunged or they speak munged (no?)

(sorry corrections)

one approach could be [unrepl blob, including completion actions][munged compliment]

to me munging is static

btw what do you think of my content-based munging idea?

it is super, also against tampering (if we wanted to)

so you munged compliment.core to compliment.core$sha1$djsfhbehsdbfhb

is it a question? if so, not yet

(what’s the limit on classname length? well Spring existence proves we have ample room)

sorry it was an hypothesis

so you munged it statically and certainly also unrepl.complete which uses it while exposing a smaller api

at the moment forms are sent over the wire in unravel: https://github.com/Unrepl/unravel/blob/compliment-blob/src/unravel/loop.cljs#L76

https://github.com/Unrepl/unravel/blob/compliment-blob/src/unravel/loop.cljs#L200

[unrepl blob, with actions referring to unrepl.complete$sha1$.../xxx][munged compliment and complete]`

if we had a :complete command action it would be different yep

in that case the action would call the munged ns and send back stuff

should work, I don't see big obstacles (right now)

actions make (I hope) lazy loading easier and interop between client and server easier. (edit: plus in case of doubt let’s have another level of indirection 😉)

even better, clients can choose what to lazy load

the action can be protected behind a delay

now the template could be (unrepl.repl/dyncall 'unrepl.complete$sha1$.... ..) with dyncall ensuring the namespace is loaded beforehand

[unrepl blob, with lazy activated actions, and side-loading]

ensuring which ns are preloaded would just be emitting a require

it improves a lot of what nRepl at the moment does (but cider-nrepl folks will soon start adding delays)

also, in this case the whole current nRepl middleware could be blobified and transformed in actions

which is very appealing

but wait...maybe I am missing something about munging

if it is content based...would all the clients end up with the same sha1?

if all versions are aligned yes

so cavalier extensions of protocols or multimethods or usage of atoms may be problematic. (more than now?)

atoms in the blob you mean? why?

if you have an atom in a lib and you modify it thinking you are the only user...

uhm right, I had in the back of my head to have a session-based munging actually...

you could put the atom in a session-based munged ns and that is only yours

I’m talking about atoms in random libs

not session state

at some point per-connection ns (with automatic removal) was considered for socket repl if memory serves me

if we munged all the namespaces involving session, all those vars would effectively be available to the session only (even libs right?)...just throwing it there, haven't thought about implications

what are we trying to achieve? maximal protection against badly written code used by extensions?

if we are already protected from conflicting with application code, it’s a good enough protection for me

no well, but your concern is valid, if a library is stateful, the state will be reflected to all the clients

an example would be tools.namespace

What's the problem with it?

https://github.com/clojure/tools.namespace/blob/master/src/main/clojure/clojure/tools/namespace/repl.clj#L91-L94

not saying we cannot solve this, just putting it there...this is a pretty common thing that a user would want to do in a repl

@richiardiandrea true but it's not a class of problems that is made worse by unrepl.