Klient.com - ircd profiles

Klient.com > Forums > Klient Related > Suggestions > ircd profiles

Last Thread Next Thread

Author

Thread

quension
Apparent Geek

Registered: Sep 2002
Location: WA state coast, USA
Posts: 1037

ircd profiles

With all the problems with things like the same numeric meaning different things on different servers, incomplete or missing RPL_ISUPPORT (numeric 005) data, useful features Klient doesn't take advantage of, etc, I think the real solution is to push support of all that out to the people with the time to do it. Here's how it could work.

IRC servers generally send their ircd name and version as the second parameter to numeric 004. Klient should use this to choose a server profile to use, which contains settings and translation information specific to that ircd.

A server profile would be a self-contained ball of information, packaged in its own file format (much like KLDs). This would allow anyone to create and distribute them, and they could be eventually included in Klient's installation as well.

Each server profile has a Match field, which is a regular expression to use against the version token extracted from numeric 004. The Match fields for all server profiles are internally sorted by length, and tried in order of longest to shortest. This allows specific server (sub)versions to be chosen ahead of more generic profiles, without having the user be responsible for correct match order. When Klient initially connects to a server and finds a matching profile, the information described below is loaded.

Settings should include everything in Klient's options, commands, or extracted from numeric 005. When a setting is also available in Klient's options or via commands, those should override the profile. A given profile should selectively override anything contained in numeric 005. By "selectively" I'm imagining a simple "use this" checkbox for each item in the profile, or a convention of leaving the profile field blank, or similar.

[ ] IRCX capable

[ ] Use PART reasons

[ ] Ban Exceptions supported, as mode character _

[ ] Invite Exceptions supported, as mode character _

[ ] Modes per line: __

[ ] Extended channel prefixes [ Define... ] (GUI version of 005's PREFIX)

...

Besides the basic settings, a profile should also contain a script. This script should be confined to a single language, must be completely isolated from all other scripts (both of the regular Klient type, and from other server profiles), and must not have the typical set of Klient objects injected into its namespace. Performance is key here, and that means as little COM interaction as possible. Instead of using the Variables object, all persistent state should be stored in language-defined variables in a single Global-style section. Instead of using StrUtils, all string manipulation must come from the language itself. And so on...

I did consider suggesting DLLs instead of scripts, but I think the packaging requirements would make them harder to deal with overall. The script engines also seem to be fast enough as long as there is very little COM work.

The script would be able to define code for one of each kind of available event, except for the Numeric event, where it becomes one of each individual numeric. A runtime error during script execution results in a single detailed error message, then the script is disabled and no events within it are executed for the remainder of that server connection.

All events need access to information about the current server, so a Server object must be available at all times. This could either be a parameter passed in to each event, or if you're still using a single server object internally, a reference to that object could be injected into the script's global namespace.

A Numeric event defines the numeric code it belongs to. When Klient receives a numeric from a server and gets a match, it calls the event with three parameters: the source of the numeric (string), the destination (string), and all remaining text (string). The script can do any processing it wants to, but once the event is complete, Klient must drop the original numeric data and do no further processing itself. If an error occurs during script execution, Klient will disable the script and proceed to handle the numeric text itself, as if there were no matching event.

Now the cool part: Klient would define a global method, say NumericResponse, that takes parameters containing a code and any additional information needed. The code would be an internal identifier that indicates a specific response to Klient. For example, I've previously mentioned some numerics that have multiple meanings. For a bahamut ircd profile, the script would process numeric 437 and call NumericResponse(CANT_CHANGE_NICK_WHILE_BANNED, '#ChannelName'). A hybrid/ratbox/comstud ircd profile would instead call NumericResponse(RESOURCE_UNAVAILABLE, 'EntityName').

Note that the code names are merely placeholders in this case. As annoying as it might be to deal with, I would suggest that the actual script code not use names, but instead use plain integers taken from a documented table. A name would imply COM overhead to get a property value, which is undesirable. Of course, nothing is preventing the script from defining its own constants and using them.

Klient should define all the responses it knows about, as well as some more generic ones that accept a textual reason to present to the user. For example, RFC1459 defines separate numerics for being unable to join a channel due to limit, invite-only, ban, and key. Klient should define codes for those, as well as one more for "unable to join due to [blank to be filled by script]".

But wait, there's more!

Besides numeric translation, there are also some ways server profile scripts can help Klient make the best use of server resources. As mentioned here, Klient uses WHOIS to look up the address of a client. If a server supports USERHOST in a useful way, a script could use that command to get the result more efficiently. How? Klient would define an event, Lookup Address, and pass in the target nickname. The script would be free to send whatever it likes to the server to accomplish that goal. When it gets a response, it would call AddressResponse(SUCCESS, 'nick', 'address') or AddressResponse(FAILED, 'nick').

A more complex example would be support for server-side filtering of the LIST command. For this event, I would like to have two sets of checkboxes (or whatever), both about the same search type. One checkbox means a search parameter of this type is supported, and the other means it will perform filtering on the server side. I'll explain the duality in a moment. Types could include member count range, channel age range, topic age range, accepted name mask, excluded name mask, accepted topic mask, etc.

Now, the reason for two sets of checkboxes for the same thing are to enable special searches in the GUI. Many current servers support server-side filtering of the channel's age (relative to its creation date), but that information is not directly returned during a LIST response. Thus, if server-side filtering is not supported, Klient (or more precisely, the ircd profile script) can't get that information to filter on itself, and should not expose that search option in the GUI. The first set of checkboxes would allow a server profile to enable as much as possible. The second set is merely an indication to Klient of which types it needs to perform filtering on itself.

And more event possibilities: Queue and Slow Queue. These would be called with a single argument, the IRC message string Klient intends to send to the server. Instead of calling a global method to indicate results, these script events would simply return an integer: the number of milliseconds to wait (relative to the previous item in the queue) before sending this line to the server's socket. This would allow ircd profiles to more precisely match the server's flood mechanism.

This turned out to be quite long and somewhat complex, but I think something along these lines would be worthwhile. It would allow others to do "compatibilty matching" between Klient and the various strange ircds out there, and Klient would only need to concentrate on the semantic actions themselves.

25 Aug 2004 05:24 AM

tom
Klient Author

Registered: Sep 2002
Location: Blacksburg, Virginia, USA
Posts: 1543

/me sets aside a weekend on his calendar to read Quension's post

__________________
Tom McAlee

25 Aug 2004 06:01 AM

codemastr
Senior Member

Registered: Oct 2003
Location: Pennsylvania, USA
Posts: 648

Most of what you said seems crazy to me:

quote:
The Match fields for all server profiles are internally sorted by length, and tried in order of longest to shortest. This allows specific server (sub)versions to be chosen ahead of more generic profiles, without having the user be responsible for correct match order.

How does length translate to specificity? .* is shorter than ... and .* matches more. .{0,} is longer than .+ however, .{0,} matches more. You can make no inference about specificity based on length of a regexp. The best way to manage an order is, as always, let the user specify the order.

The script idea can already be done. The stuff you are suggesting is the exact stuff I'm doing with my SSL dll, except, the way I'm doing it is significantly more efficient. First of all, compiled code is going to be faster than any scripting language. Second, Klient doesn't even get a chance to do "event translation," I'm intercepting it right from the socket, before Klient even receives it! So that's a much faster way to do it. It's more complex, yes, but what you're suggesting already requires the user to be extremely knowledgable, so if he/she can't figure out how to do such interception, then he/she probably can't get all this working anyway.

But anyway, I don't think this feature is worth it. Who will use it? How many people here know enough about each IRCd to make a 100% accurate, bug free implementation for it? Probably only the people who wrote the IRCds. I'm a Klient user, and I probably wouldn't feel like writing a protocol specification for UnrealIRCd, sounds like it would take me longer to do that than it would for me to just tell tom, "numeric 123 doesn't work in Klient" and have him fix it. But, imagine the reaction you'd get from someone who doesn't care at all about Klient!

The idea is interesting, but it seems rather foolish to me. Basically, you want to place the onus on the user. You want tom to abstract Klient in such a way that it is the user's responsibility to code in the IRC functionality... if that's the case, the next logical step is to just write your own client! It would definately be nice in some instances, but I'm willing to bet this would take tom several months to do, and you'd probably be the only one who is willing to take the time necessary to actually make use of it

Instead, I'd rather see tom add better support for numeric 005, there are still a bunch of tokens Klient does not support. I'd rather Klient make sure it is capable of running with future servers, than making sure it is capable of running with the 1-2 servers that are still living in the past.

__________________
-- codemastr
"I'd prefer to keep mIRC a scripting language and not a programming language" -- mIRC Forum Poster

25 Aug 2004 06:40 PM

tom
Klient Author

Registered: Sep 2002
Location: Blacksburg, Virginia, USA
Posts: 1543

This is probably discussed somewhere else, but what tokens in the 005 does Klient not support that it could make some use of?

__________________
Tom McAlee

25 Aug 2004 09:57 PM

quension
Apparent Geek

Registered: Sep 2002
Location: WA state coast, USA
Posts: 1037

quote:
How does length translate to specificity? .* is shorter than ... and .* matches more. .{0,} is longer than .+ however, .{0,} matches more. You can make no inference about specificity based on length of a regexp.

It's not intended to be exact, only a rough guide. What matters is the length of the real text, not the expression itself. And as you pointed out, it's easy to artificially inflate or decrease the length of a given regexp, provided the engine supports advanced features. I'm not expecting advanced feature support though -- the reason for allowing regexp in the first place is to match version numbers more easily.

quote:
The best way to manage an order is, as always, let the user specify the order.

Not for this. The users won't have a clue what this stuff is, which is exactly the point -- it's merely a background tool to make Klient work better for them. They shouldn't have to understand how ircd names are matched and enough regex to decide what the best order is.

quote:
The script idea can already be done. The stuff you are suggesting is the exact stuff I'm doing with my SSL dll ...

Actually it can't, and it's not. This stuff requires some additions and abstractions for Klient in order to adequately be supported. And that's just to do numeric translation -- an interception DLL can't handle LIST, address lookup, or queueing at all.

quote:
... except, the way I'm doing it is significantly more efficient. First of all, compiled code is going to be faster than any scripting language. Second, Klient doesn't even get a chance to do "event translation," I'm intercepting it right from the socket, before Klient even receives it! So that's a much faster way to do it. It's more complex, yes, but what you're suggesting already requires the user to be extremely knowledgable, so if he/she can't figure out how to do such interception, then he/she probably can't get all this working anyway.

No, it's not the same at all. Interception methods are much more complex than understanding the IRC protocol. There is also no way for the current DLLs doing inteception to safely/reliably coexist. For example, if my accept patch is loaded along with kSSL, there's a 50% chance that unloading one of them will cause Klient to crash. There's also a miniscule chance that loading one of them will crash instantly. So far I consider both scenarios to be unlikely enough to avoid addressing. That won't hold if there are going to be several of them loaded.

An interception DLL also requires an intimate understanding of how Klient handles network I/O. And that's even slated to change at some point in the future! Interception DLLs are a hack, plain and simple. They aren't meant for serious deployment with a piece of software under active development.

Understanding what numeric an ircd sends, what it should mean to Klient, and the small bit of script code necessary to translate it is far easier.

quote:
But anyway, I don't think this feature is worth it. Who will use it? How many people here know enough about each IRCd to make a 100% accurate, bug free implementation for it?

Klient will still have default handling internally, and can do whatever magic it does now; that doesn't need to change. That makes this feature an incremental thing -- interested people can add to it as they want to.

quote:
sounds like it would take me longer to do that than it would for me to just tell tom, "numeric 123 doesn't work in Klient" and have him fix it

The cool thing about this is that users can post here saying "Klient shows ... when I try to join a channel on ... server, but that message is wrong", and anyone with the ability can go create or tweak a server profile and post it for them. Tom can either include what they post, or just make the changes himself, and distribute the resulting profile in the next release. Either way it's the same result, and would be the same amount of work as changing it within Klient directly.

quote:
The idea is interesting, but it seems rather foolish to me. Basically, you want to place the onus on the user. You want tom to abstract Klient in such a way that it is the user's responsibility to code in the IRC functionality

Actually no, I just want it exposed it in a way that makes it possible for developers with the time to research these issues to make the changes themselves and get instant results, as well as keep the workload for this away from Tom. Again, Klient would keep all the defaults it does now, and server profiles wouldn't need to be created full-featured. It can be an incremental thing -- you just go add a numeric translation when you discover it's wrong. In the meantime Klient behaves as it has always done -- works on most servers, and if it breaks it just goes on broken. The difference is we don't have to wait for Tom to get time to do the research and make the changes, if there's an interested person who can do it instead. Basically the same situation as any other script or plugin, just with more focus on protocol details.

quote:
Instead, I'd rather see tom add better support for numeric 005, there are still a bunch of tokens Klient does not support. I'd rather Klient make sure it is capable of running with future servers, than making sure it is capable of running with the 1-2 servers that are still living in the past.

Of course I want better support for 005 as well, but 005 is incapable of addressing everything this feature would. I made this suggestion exactly because there is absolutely nothing on IRC that's capable of covering this, RPL_ISUPPORT and HANDSHAKE included. Also note that the LIST suggestion is a bit extreme. I'd certainly be happy with 005 ELIST support instead of everything this does, but I would still want the ability to specify what a non-005-sending server supports in ELIST terms.

Other clients do some of this already -- they sense an ircd version and handle it specially. Tom has resisted doing that because it's not a good situation to be in. However, it seems evident that such support is needed, and this idea would make it dynamic enough to avoid the maintenance problems that come from hardcoding it internally.

26 Aug 2004 01:01 AM

codemastr
Senior Member

Registered: Oct 2003
Location: Pennsylvania, USA
Posts: 648

Still sounds crazy to me. I refuse to run scripts written by other people. I'm definately not going to run a script written by someone else when that script basically controls whether Klient works or not. Maybe others think this is a great idea, I just think tom's time would be much better spent elsewhere.

__________________
-- codemastr
"I'd prefer to keep mIRC a scripting language and not a programming language" -- mIRC Forum Poster

26 Aug 2004 04:29 AM

tom
Klient Author

Registered: Sep 2002
Location: Blacksburg, Virginia, USA
Posts: 1543

I'll let you know what I think when I actually read it. It is scheduled for the 3rd weekend of September

But... answer the question in my last post!

__________________
Tom McAlee

26 Aug 2004 04:31 AM

codemastr
Senior Member

Registered: Oct 2003
Location: Pennsylvania, USA
Posts: 648

quote:
This is probably discussed somewhere else, but what tokens in the 005 does Klient not support that it could make some use of?

Sorry, in all the techno-craziness discussions I didn't even see your question

ELIST - This would make /list MUCH better

WHOX (ircu specific)

CASEMAPPING could be better implemented - meaning, StrUtils always uses the old [ = { stuff. Not all servers do that. It would be nice to have some method that would allow you to compare strings using the mapping done by the server you're running the script on.

Those are just some of the ones I can think of at the moment.

__________________
-- codemastr
"I'd prefer to keep mIRC a scripting language and not a programming language" -- mIRC Forum Poster

26 Aug 2004 04:38 AM

tom
Klient Author

Registered: Sep 2002
Location: Blacksburg, Virginia, USA
Posts: 1543

ELIST and CASEMAPPING I knew of; they're on some list of things to do somewhere

This is the first I've heard of WHOX though.

__________________
Tom McAlee

26 Aug 2004 04:42 AM

codemastr
Senior Member

Registered: Oct 2003
Location: Pennsylvania, USA
Posts: 648

WHOX is an interesting idea, some features of it are nice, others are rather un-user friendly. But one thing that is definately nice is the "query identifier" meaning, it lets you register a number that the server will return for all the numerics generated as a result of that /who. It is nice for things that do a /who and want to supress the output since it ensures you are only supressing the correct output.

__________________
-- codemastr
"I'd prefer to keep mIRC a scripting language and not a programming language" -- mIRC Forum Poster

26 Aug 2004 04:49 AM

quension
Apparent Geek

Registered: Sep 2002
Location: WA state coast, USA
Posts: 1037

quote:
I'll let you know what I think when I actually read it. It is scheduled for the 3rd weekend of September

*taps foot* :P

23 Sep 2004 08:00 PM

martini
Junior Member

Registered: Aug 2004
Location:
Posts: 2

bump!

23 Sep 2004 09:32 PM

RMerlin
Junior Member

Registered: Aug 2004
Location: Montreal
Posts: 8

Third weekend of September has come and gone, think Tom is trying to book another week-end for his answer to you?

/me ducks for cover.

---
RMerlin

24 Sep 2004 02:32 AM

quension
Apparent Geek

Registered: Sep 2002
Location: WA state coast, USA
Posts: 1037

Probably the 6th weekend of October :D

24 Sep 2004 03:26 AM

MerlinCorey
Pimpin' Magician

Registered: Sep 2002
Location: California
Posts: 216

Heh, well, Codemastr can think it's crazy, but I like the idea,personally... And I will say I'm willing to challege codemastr's alphabet soup (since I run it and so do two other networks I'm on) and do the server profile for it, if need be... Whether it is script or dll... Maybe because I'm naive, but I agree that scripts wouldn't be fast enough, so I'd rather it have a DLL interface...

But then again, I'm sure Tom doesn't want to enter DLL Hell with tons of DLLs or Scripts that must be loaded with Klient to get this functionality... So... Maybe it's just not going to happen ...

__________________
mCorey - or as some would say, "mmmCorey"...

24 Sep 2004 08:33 AM

tom
Klient Author

Registered: Sep 2002
Location: Blacksburg, Virginia, USA
Posts: 1543

Sorry, I had to reschedule for the 11th week of January.

Actually, its just that I have enough going on to try to get 2.1 out there. Since this isn't something that would be part of 2.1, time constraints prevent me from giving it the full consideration it deserves.

I will read it... feel free to argue about it now though and maybe it will be ironed out when the time comes where I actually start picking off items to implement in the next release.

__________________
Tom McAlee

24 Sep 2004 11:11 PM

quension
Apparent Geek

Registered: Sep 2002
Location: WA state coast, USA
Posts: 1037

FWIW, I'm not so keen on the proposed implementation of this anymore (scripting etc). I still think some form of "ircd profile" support is needed, I'm just not sure what it should look like.

24 Feb 2005 11:57 PM

All times are GMT. The time now is 10:32 PM.

Last Thread Next Thread

Show Printable Version |

Email this Page |

Subscribe to this Thread