Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2018-03-14

Channels

#unrepl
<
2018-03-14
>
kotarak12:03:03

Ah! Idea! I can merge the action maps client side! šŸ˜ø

cgrand12:03:10

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

cgrand12:03:59

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)

cgrand12:03:45

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

cgrand12:03:25

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

kotarak13:03:39

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.)

kotarak13:03:00

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

kotarak13:03:40

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.

cgrand13:03:33

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.

cgrand13:03:21

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

kotarak14:03:26

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

kotarak14:03:40

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

cgrand14:03:05

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

kotarak14:03:16

Regarding advertising on aux: does it hurt?

kotarak14:03:50

Yes. I know. I did otherwise. šŸ˜ø And it worked. šŸ˜ø

cgrand14:03:29

It adds code and state and I perceive no value.

kotarak14:03:53

Then don't do it.

cgrand14:03:09

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

kotarak14:03:30

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

kotarak14:03:51

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

kotarak14:03:48

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.

kotarak14:03:00

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

kotarak14:03:59

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

kotarak14:03:16

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

cgrand14:03:48

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.)

kotarak14:03:28

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.

kotarak14:03:50

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.

kotarak14:03:44

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.

kotarak14:03:05

? Slack......

kotarak13:03:27

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.

kotarak13:03:48

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

kotarak13:03:46

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

kotarak13:03:00

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

kotarak13:03:02

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