[Konversation-devel] [Bug 132608] Add option to defer auto-commands until certain conditions are met

[Eike Hein]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132608         




------- Additional Comments From hein kde org  2007-07-20 23:48 -------
For the record: The reason we're not currently doing this isn't because we're lazy or because we're stupid, but because it's non-trivial, or rather because the only "solutions" are extremely unattractive.

Authentication on IRC is essentially unstandardized, despite multiple efforts to correct that problem over the years (the latest of which is IRC+, which we're involved with to some degree). There's no reliable protocol by which to authenticate and wait for success or failure. 

The first thought tends to be "so just delay that stuff by a few seconds". That solution is undesirable for a number of reasons:
* If the amount of time to wait is fixed and too low, it enters the realm of being unreliable; creating potential race conditions due to variable latency.
* If the amount of time is fixed and too high, it's detrimental to the user experience: Connecting to a network takes longer for (to the user) unclear reasons.
* If the whole thing is to be optional and the delay configurable, we're dealing with an ugly option cluttering up the UI.

A better solution what we're calling "the contingency waiting scheme", which roughly works as follows:
* If the Auto-Identify fields are filled in, the authentification command is sent as early as possible in the connection process. Similarly, if one of the auto-connect Commands matches one in a list of known authentification message patterns, it's singled out and sent first.
* Auto-join and the other auto-connect commands are deferred until a timer set to a fixed amount times out. 
* If a known authentification success message is received prior to timeout (checked against a white list), the timeout is pre-empted and auto-join and commands commence immediately. The same for a known failure.

The reason that solution is undesirable is that it opens up the Pandora's Box of trying to abstract all the different services implementations out there by collecting their replies and shipping the lists in the app, and keeping them updated.

The third solution is to defer the problem to the user: Add a scripting interface that allows power users to upload some code into the app that disables automatic auto-join/commands and instead triggers it when recognizes an incoming message as an authentification success. I find that degree of customizability/scriptability to be desirable and we will strive to attain it, but as a solution to this problem it's ultimately rather user-unfriendly.

Thus we're currently leaning towards option #2, but implementing it is definitely not our idea of a good time.