On Oct 20, 2009, at 11:02 PM, James Hess wrote: On Wed, Oct 21, 2009 at 12:07 AM, Trevor Talbot <quension@mac.com> wrote:
example, consider those old-school scripts that automatically remove bans placed against yourself.
I'm not sure it's a good example. The user of that script has the option to forego masking in favor of continuing to use that particular script.
It's not a particularly good example on its own, no, but it does demonstrate that the issue affects not just server and client implementers, or even script writers, but end users as well.
ages. The assumption that a host does not change was embedded in IRC behavior when hosts were added. It's visible in the way server- side things like channel bans are handled, how stateful clients gather and apply
I don't believe anything major breaks too badly when masking is implemented in violation of those assumptions that doesn't also break when those assumptions are preserved.
IRC clients in general do not keep long term record of channel member list information. Some cache it to varying extents. Some do keep the information. Someone's assumptions will be violated, no question.
I agree, and it's fairly obvious by the number of popular hostmasking implementations out there that everyone involved has dealt with the small issues in some way and that nothing major is left. My point is that changing such an assumption causes small issues in a very widespread area; servers have to create workarounds specifically to keep clients happy, modern clients have to create workarounds for state management purposes, and script writers have to be aware of the trouble clients are having with state and deal accordingly. End users get stuck with the fallout. That's a sign of a badly implemented feature. (Or a badly designed protocol, but we've had that discussion before...) I respect the people implementing hostmasking; it is, after all, an organically grown feature like the rest of IRC. However, like most network services, most implementations appear to be bolted on rather than integrated as much as possible, and so I am not happy with them. With the experience learned from those implementations it should be possible to do better.
So far the justification for preserving these assumptions at the cost of some increased complexity seems pretty questionable...
Why is the ability to opt out of hostmasking in realtime considered so desirable that it is worth the violation of the host-immutability assumption and all of the associated ill effects? -- Quension