Two related items from the PR #1 discussion about session establishment.
- @imrekoszo asked why the op is called
clone rather than something like new-session, and followed up asking for the explanation to live in the doc. @alexander-yakushev explained that the name is literal: when invoked on an existing session, it clones that session's state (notably dynamic-variable bindings); when invoked without a parent session, there's nothing to clone yet. The spec should say this.
- Now that the spec asks clients to send
describe immediately on connecting, @technomancy suggested folding the two together into a single register op that returns describe-style info and also registers a session. Worth a real discussion before doing anything.
My take:
- I'm open to the
register op idea, though we could probably retrofit clone to do the same thing.
- Even if we introduce a new op, I'd probably keep
clone around for backwards compatibility.
- In general I like it when all ops are verbs.
completions is an exception for historical reasons (to avoid collisions with cider-nrepl), but down the road anything is possible.
Two related items from the PR #1 discussion about session establishment.
clonerather than something likenew-session, and followed up asking for the explanation to live in the doc. @alexander-yakushev explained that the name is literal: when invoked on an existing session, it clones that session's state (notably dynamic-variable bindings); when invoked without a parent session, there's nothing to clone yet. The spec should say this.describeimmediately on connecting, @technomancy suggested folding the two together into a singleregisterop that returns describe-style info and also registers a session. Worth a real discussion before doing anything.My take:
registerop idea, though we could probably retrofitcloneto do the same thing.clonearound for backwards compatibility.completionsis an exception for historical reasons (to avoid collisions with cider-nrepl), but down the road anything is possible.