Re: 28.0.50; buffer-naming collisions involving bouncers in ERC

[Olivier Certner <ocert.dev@free.fr>]

Hi,

> The current approach
> 
>   "The only way to do it is connection=network" - Irssi's maintainer [6]
> 
> I'd like to believe ERC's authors basically agreed with this, at least
> in spirit. And while their whole ad hoc/dynamic way of assigning
> connection identities is a bit different, I don't think there's any
> reason to abandon it just yet, especially if we strive to place more
> emphasis on understanding and applying the evolving standard going
> forward.

This approach seems to have drawbacks, at least in principle. For example, I 
don't think it allows to connect and join different channels with different 
nicknames at once. Surely, this is not the most straightforward scenario, but 
maybe some people would be interested in doing that. I would be interested, 
for example. Of course, if the principle above is rooted into ERC, many 
changes are going to be needed in practice to allow multiple "sessions", so it 
doesn't matter much if the proposal below is at odds with that (it won't 
worsen the situation compared to now). Multiple sessions can be dealt with 
independently at some later point.
 
> Here are a couple of assumptions that had better hold if my present
> angle of attack is to get us off the ground:
> 
> 1. There is at most one connection from a client to a network at any
>    given moment [7]
> 
> 2. Buffer->network associations cannot change once determined, i.e.,
>    networks and ERC buffers mate for life, even when disconnected
> 
> (snip)

I think there are two essential points to be made here:

1. Separate the network (or the session), seen as the user's target, from the 
means to connect (directly or through a bouncer, or whatever else). This way, 
there is no confusion between the transport part (just a mean) and the session 
(which is what matters to the user in terms of context, i.e., which network 
I'm in (and channels) and under which identity).

With this, there will be no problem in the scenario where one connects to a 
bouncer to do maintenance tasks while there is already a connection to it to 
access some other network. There will be two sessions: One for the maintenance 
task, designating the bouncer, and one for the other network, each having its 
own connection and separate buffers. I think that having a single connection 
to the bouncer in this particular case is a refinement that could be 
implemented later (or not), unless of course it is absolutely impossible to 
have more than one at a time (is it the case with usual bouncers?).

2. Also, buffers should not be associated on the fly to networks, depending on 
what the network says. They should be associated to sessions, as a priori 
targets specified by the user, with unambiguous (i.e., different buffers for 
channels with same name in different sessions) and unchanging names (may be 
internal "names" of any form instead of the buffer name, if one wants short 
buffer names in common situations). This way there is no "dangling" buffer, 
and it is always very clear which buffer belongs to which session, enabling 
smarter management in case a session is disconnected and then reconnected, or 
log storing. 

I don't know precisely which changes 1 and 2 require given the current code, 
but I intend to dig that at some point. Unfortunately, I don't think I'll be 
able to before weeks, probably even months. At least, I hope we can agree (or 
if not, discuss) on these target points.

-- 
Olivier Certner