Rizon Features Expansion Discussion

[SecretAgent]

Not entirely, it must also use SJOIN to introduce those clients to channels during a netburst, but that isn't all that burdensome.

The biggest issue is that BotServ requires channel traffic to go through services, for little gain IMO. This wouldn't change if we were to incorporate BotServ features, such as badword lists, into ChanServ. However, it would be one service, making it more practical from both a development and end-user standpoint.

[Celestin]

Services act as server and as such they get channel traffic anyways, it just depends what they do with it

[NiTeMaRe]

I understand your point and I do agree with your conclusion. Truthfully I was already fully aware that an implementation such as I have suggested would have the ramifications you alluded to. However I am an advocate of customization and I am still of the belief that such a feature would be a great addition for BotServ; concurrently the process as I have defined may not be the optimum method for this idea as you have shown. With regards to this matter I will continue to think of ways to reinvent this idea.

With regards to the complete abandonment of BotServ however, I cannot be in total agreement with that conclusion. Simply BotServ still holds or carries with it a certain level of necessity and functionality currently not provided by ChanServ (such as flood control; kicks for excessive repeats, bolds etc.). If users are aware of this and if they are utilizing this functionality is a different matter.
What I can agree on, is if all BotServ's functionality is integrated within ChanServ (including flood control etc.) that would increase ChanServ's functionality and flexibility exponentially, whilst reducing the overhead costs associated with the separate BotServ.

------------------

Miikaii <--> Miichiio
#infaxel.net@irc.rizon.net
"Hoping business class features can be given to coach. Enjoy flying Rizon."

to clarify all of botserv's functionality would be transferred to chanserv of course.