AW: [IRCServices] Is there a timeline in the future for supporting ircd2.9 or greater

Andrew Church achurch at achurch.org
Tue Aug 6 10:35:01 PDT 2002


     This more or less summarizes my feelings on the matter, though I will
comment that I don't consider SVSNICK/SVSMODE essential parts of Services
(I personally prefer nick kill to nick change).  But no, I have no plans at
the moment to support this ircd.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>
>Hi,
>
>though I am not an authority, I would say NO, because ircd2.10 
>and later is not designed to work with a services server 
>(and not SERVICE's which are a totally different kind), 
>because of the following:
>
>- Lack of a global kline (akill would not work)
>- Lack of topic burst 
>- Lack of services-savvy functions like (SVSMODE, SVSNICK)
>- Lack of privilege level (like U:Line) so that certain clients 
>  can do more (kill, mode, kick, topic) without having to join
>  channels. 
>
>Unless IRCnet coders start coding their ircd to support services,
>I do not see any point in supporting that ircd, since the kludges
>and hacks to accomplish those mentioned functionality would take
>too much time.
>
>Example:
>- Instead of Autokilling, services would need to continously send
>  KILL, and this would work as long as you configure your server 
>  to allow remote KILLs.
>- After a netjoin, a channel could have different topics the amount
>  of linking servers, and services would never notice it, and
>  it also would not need resetting topics.
>- Services would even not see a netsplit happening, if:
>	bla.xxx.com splits from
>	hub.xxx.com but, hub.xxx.com represents themselves as
>	*.xxx.com and any server behind them is hidden from the
>	network.
>- Guest'ing would not work, since SVSNICK is not there.
>- In order for ChanServ to MODE #channel +o nick, ChanServ should
>  join the channel, and become op by services server, and then
>  set op on another user
>- The same for kick and topic.
>
>Moreover, ircservices cannot be redesigned to work as SERVICE's,
>because a SERVICE is not differentiated by name, but name at host,
>and this would mean, that anyone could link up their NickServ
>to the net as a service, and the best_service() thing from
>IRCnet ircd would just choose ONE optimal choise for you, leading
>to total inconsistency with registration/access lists, etc.
>
>I am additionally not sure, whether IRCnets SERVICE's are allowed
>to MODE/KICK/TOPIC.
>
>Regards;
>yusuf
>
>PS: What is actually the main reason for you to use ircd2.10 or 
>later ? I ask just because of interest. (You can answer me
>privately to this question, if you want)
>
>------------------------------------------------------------------
>| Yusuf Iskenderoglu                | You get to meet all sorts, |
>| eMail - uhc0 at stud.uni-karlsruhe.de| in this line of work...    |
>| eMail - s_iskend at ira.uka.de       |                            |
>| ICQ UIN : 20587464 \ TimeMr14C    |                            |
>------------------------------------------------------------------
>
> 
>
>> -----Ursprüngliche Nachricht-----
>> Von: ircservices-admin at ircservices.za.net 
>> [mailto:ircservices-admin at ircservices.za.net] Im Auftrag von 
>> Frederico C Wilhelms Fred
>> Gesendet: Montag, 5. August 2002 19:00
>> An: ircservices at ircservices.za.net
>> Betreff: [IRCServices] Is there a timeline in the future for 
>> supporting ircd2.9 or greater
>> 
>> 
>> Hi,
>> 
>> Is there any kind of timeline for supporting newer versions of the 
>> ircd2.(>9) ?
>> 
>> Tks
>> 
>> Fred 
>> 
>> 
>> 
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit: 
>> http://www.ircservices.za.net/mailman/listinfo> /ircservices
>> 
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices