From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Olivier Certner Newsgroups: gmane.emacs.erc.general,gmane.emacs.bugs Subject: Re: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Wed, 09 Jun 2021 16:36:19 +0200 Message-ID: <2355590.Kj97tzTlbN@ravel> References: <875yzakzvi.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7Bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4852"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bug-gnu-emacs@gnu.org To: emacs-erc@gnu.org, "J.P." Original-X-From: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Wed Jun 09 16:36:36 2021 Return-path: Envelope-to: sf-erc-help@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqzJs-00012N-BF for sf-erc-help@m.gmane-mx.org; Wed, 09 Jun 2021 16:36:36 +0200 Original-Received: from localhost ([::1]:57276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqzJr-0005Wb-8G for sf-erc-help@m.gmane-mx.org; Wed, 09 Jun 2021 10:36:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42696) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqzJl-0005UZ-Sn; Wed, 09 Jun 2021 10:36:30 -0400 Original-Received: from smtp5-g21.free.fr ([2a01:e0c:1:1599::14]:4834) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqzJj-0007Y3-Mv; Wed, 09 Jun 2021 10:36:29 -0400 Original-Received: from ravel.localnet (unknown [2.15.208.149]) (Authenticated sender: ocert.dev@free.fr) by smtp5-g21.free.fr (Postfix) with ESMTPSA id C91E85FF7A; Wed, 9 Jun 2021 16:36:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1623249385; bh=bUvkVatundz58agnuJGo/fhKguXxXo/Tf7TzUnH406w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RrOVRe0MgPbAamWqPl+ARI7HxKurI2r2ISu9ZEsIktbGlZW9ezNzvsvDpg4BrVOXV tqzK8trtkcUnJLPEX2wT1+rolYnW6G4jMSlFyb3+z1m1ZCkh+gznC+FB7jHqy6Mk8v UIe+NgTk66vuF25wgezqoAZIvVspruCK9vF/KM2zFwbDZTQKUOXvmPKUgMWxblIjKo dX7wWiBtjMZkwV9DZEPSOMTjZ1KVKQjfM0pbpsoNap2u/geRe5R/kCMBs0e1Vdq5Xb 4L7SMfmjoDKFSWku2AeC7AUg782NR9Itw+nbqLcCzZoUTFLmVkB6RvIAGdBnZ/t6lv KRavUKh+yE50w== In-Reply-To: <875yzakzvi.fsf@neverwas.me> Received-SPF: pass client-ip=2a01:e0c:1:1599::14; envelope-from=ocert.dev@free.fr; helo=smtp5-g21.free.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-erc@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion about ERC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Original-Sender: "emacs-erc" Xref: news.gmane.io gmane.emacs.erc.general:1546 gmane.emacs.bugs:208297 Archived-At: 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