[3540] in BarnOwl Developers
Re: [barnowl] IRC reconnect (#108)
daemon@ATHENA.MIT.EDU (Jason Gross)
Thu Aug 8 15:33:28 2013
Date: Thu, 08 Aug 2013 12:31:55 -0700
From: Jason Gross <notifications@github.com>
Reply-To: barnowl/barnowl <reply+i-9709132-2001beb80c08e30b034e487c72b5d6a5a38438fb-4475081@reply.github.com>
To: barnowl/barnowl <barnowl@noreply.github.com>
In-Reply-To: <barnowl/barnowl/pull/108@github.com>
----==_mimepart_5203f22b6dab7_68f7fe1d48948f
Date: Thu, 08 Aug 2013 12:31:55 -0700
Mime-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <5203f22b6fcd0_68f7fe1d4894969@worker1.rs.github.com.mail>
Quoting from comments that got lost in rebase:
> Remark: irc-join in a startup file doesn't actually work anymore. The trouble is that IRC connects are done asynchronously now, so the succeeding join will race against the connect and, more often than not, be attempted before the connection is successful.
Oh, ok. Do you think we actually want to be noisy about duplicated joins? I'm in favor of being silent, because I currently have `:irc-join`s in my startup, but I can change that.
> Do you want to describe the file format?
Sure, I'll change that.
> Per RFC 2812, spaces in channel names are illegal. So this message is wrong in some sense.
How about s/`Use the -t flag.`/`As per RFC 2812, spaces in channel names are illegal. If you really want to proceed anyway, use the -t flag.`/?
> the internal hashtable could get out of sync with the file on the system
I guess I should go see what we do with `.zephyr.subs`. Regardless, here's my current stance: because we only write the file a line at a time, we don't run the risk of clobbering others' subs (except maybe from I/O races). There's `irc-loadchannels` to load all the channels from the file, if you wrote them elsewhere. If you join a channel persistently in one barnowl, it doesn't automatically show up in another, unless you reload all the subs, and similarly for parting.
---
Reply to this email directly or view it on GitHub:
https://github.com/barnowl/barnowl/pull/108#issuecomment-22349204
----==_mimepart_5203f22b6dab7_68f7fe1d48948f
Date: Thu, 08 Aug 2013 12:31:55 -0700
Mime-Version: 1.0
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <5203f22b709db_68f7fe1d48950fb@worker1.rs.github.com.mail>
<p>Quoting from comments that got lost in rebase:</p>
<blockquote>
<p>Remark: irc-join in a startup file doesn't actually work anymore. The trouble is that IRC connects are done asynchronously now, so the succeeding join will race against the connect and, more often than not, be attempted before the connection is successful.<br>
Oh, ok. Do you think we actually want to be noisy about duplicated joins? I'm in favor of being silent, because I currently have <code>:irc-join</code>s in my startup, but I can change that.</p>
<p>Do you want to describe the file format?<br>
Sure, I'll change that.</p>
<p>Per RFC 2812, spaces in channel names are illegal. So this message is wrong in some sense.<br>
How about s/<code>Use the -t flag.</code>/<code>As per RFC 2812, spaces in channel names are illegal. If you really want to proceed anyway, use the -t flag.</code>/?</p>
<p>the internal hashtable could get out of sync with the file on the system<br>
I guess I should go see what we do with <code>.zephyr.subs</code>. Regardless, here's my current stance: because we only write the file a line at a time, we don't run the risk of clobbering others' subs (except maybe from I/O races). There's <code>irc-loadchannels</code> to load all the channels from the file, if you wrote them elsewhere. If you join a channel persistently in one barnowl, it doesn't automatically show up in another, unless you reload all the subs, and similarly for parting.</p>
</blockquote>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href='https://github.com/barnowl/barnowl/pull/108#issuecomment-22349204'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/JJk3yKd0u6qAmPAmJXdf9_gRuUTQCipO-dP0x97pmbFICXxk9_eKsAFlYwLIF2Vi.gif' height='1' width='1'></p>
----==_mimepart_5203f22b6dab7_68f7fe1d48948f--
