Clojurians Log v2

Ah! Idea! I can merge the action maps client side! 😸

@kotarak the (start) without map in start-aux is indeed wrong but I believe your solution is not right (conceptually)

extensions maps allow to expose context-free actions, there’s no value in readvertising them on aux (the client already got them on the main conn)

also what would we do if we allow dynamic advertising? broadcast the advertising to all related conns?

Maybe they should even be advertise separately from session actions (the real ones which depend on session)

With blob-independent action map read my need for dynamic registration diminished. I can built the actions dynamically on the client. For session they then can be static. (My problem is blob generation. But with independent actions that isn't necessary anymore.)

Regarding auxed connections. Why shouldn't they advertise the possible actions? You don't know how they are used on the client.

Your view was always the initial connection to be the user connection and the tooling conn auxed from there. I actually do it the other way around. The initial conn is tooling. User repls are auxed.

I don't see why it should be conceptually wrong to broadcast what the connection can do. Because most actions don't care about the actual connection used. Actions needing a side channel like interrupt notwithstanding.

I agree that dynamic actions may shoot over the target. Maybe they are a XY-problem.

Dynamic actions vs. static actions with dynamically provided action map vs. static actions with static blobbed actions.

My problem was the latter. So I desperately proposed the former. My changes implement the middle. And that works quite well.

Whether the additional actions are advertised on auxed connections is completely orthogonal.

My view is that whatever a client pref, there will be always a “first” connection. It’s enough to have this connection adverstising “familiy-wide” actions.

Likewise if dynamic advertising come to be the rule could be that actions announced on any connections are merged.

Yes. As I said. Maybe dynamic action definition is too much.

With "your view" I meant what you used always as example in past discussions. Sorry if I got that wrong.

That’s true that I usually consider the first one to be the user repl but there’s nothing preventing you from doing otherwise

Regarding advertising on aux: does it hurt?

Yes. I know. I did otherwise. 😸 And it worked. 😸

It adds code and state and I perceive no value.

Then don't do it.

All this discussion is pushing me to revise the spec to discuss of sibling connections

(I'm not sold on either way. Just asking stupid questions.)

Although it may add code and complexity on the client since there are now several types of flavours of actions.

I can understand there is a master connection which has the sideloader attached (possibly). New connections are auxed from there. Then auxing a connection from an auxed connection should work as if it was done from the initial one.

Nope.

The first connection creates a session with sideloader attached to the session. No master connection.

And connections are auxed from the session. Not a connection.

(This just a brain dump of what I'm thinking while typing. Does any of that make sense?)

family/group: shared classloader, has actions (start aux and start side loader would be amongst them) session actions (setting limits etc.) msg actions (interrupt etc.)

I do not understand problem with the actions. They are advertised and they can be send through any connection belonging to the same family (what I called session). The only thing to keep in mind: the effect the *vars of the used connection.

The scope is completely irrelevant since it is provided by the action already. Eg. Set-source already brings the connection id! There is no difference to eg. a conn-unrelated doclookup request for tooling.

I do not understand problem with the actions. They are advertised and they can be send through any connection belonging to the same family (what I called session). The only thing to keep in mind: they affect the *vars of the used connection.

? Slack......