[IRCServices] Services Suggestion - NickServ

[Mark Hetherington (Eurocom)]

> I do not see your point. I do not think, that services should
> handle causalities
> of what possible JavaChat daemons may have done to your network.
> If you really cannot live with that specific daemon, you will
> need to recode services
> to live with it, and not enforce me to compile a code specific to
> your network.

This issue is not specific to my network. The most common Java client I see
is Jirc over which only the writers have control over and is installed by a
number of users covering a number of channels on a number of networks hence
my suggestion for the benefit of all networks.

It was merely a suggestion and I have every intention of doing it myself for
the benefit of my users which ultimately is the aim of improvements in
services and ircd coding.

> First of all, that nickname event may be solved in your javachat daemon.
> You should be able to modify it to either
> - not suggest a default nick

If you have access to the code to change it yes. Otherwise no. Since most
Java clients in use are not open source changing them is not an option. I do
not have any desire to code one myself but see no benefit in avoiding their
traffic to the network.

> - change the suggestion to Guest* and not JavaGuest*
> Or, you can use another daemon.

These are down to individual user preferences. For example a #Millennium
channel use MilGuest as their Jirc guest nick. In the same way I have no
control over what client someone uses to connect to the network I cannot
control which other interfaces a channel owner will use to bring users to
his or her channel nor should I. By the same token if it is beneficial to
more than one user it seems worth the effort to support this new wave of
client and to remove the load on channel owners and opers managing the guest
nicks becoming registered.

> And second, that condition is not a case services should handle
> in my opinion.

Everyone is entitled to that but you seem to be under the impression this
was specific to my network. It is not otherwise I would handle it locally
and not suggest an improvement that may benefit others.

IRC is constantly evolving with a number of alternatives having appeared but
none yet to really compete with it. The type of user we see these days is
increasingly of the layman breed rather than the original more technical
users of IRC so tend to use easier programs. Java interfaces are something
which are accessible on a number of platforms and are being integrated into
other programs as an alternative to coding an IRC client. Rather than ignore
these users, I hope that networks can evolve to accomodate them. As they
become regular users they will migrate to a dedicated IRC client program at
some stage.

Obviously there is a line between what should be client side, what should be
server side and what should be in services. But I do not think we should we
ignore the grey areas just to stay in black and white.


Mark.
CTCP Networks.