software/RELEASES/ircservices/achurch.org/services/lists/ircservices/2001/001480.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices] Services Suggestion - NickServ
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Services%20Suggestion%20-%20NickServ&In-Reply-To=NDBBKLOOKLMAKHFICBLCGELFEIAA.uhc0%40rz.uni-karlsruhe.de">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="001479.html">
  11    <LINK REL="Next"  HREF="001481.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices] Services Suggestion - NickServ</H1>
  15     <B>Mark Hetherington (Eurocom)</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20Services%20Suggestion%20-%20NickServ&In-Reply-To=NDBBKLOOKLMAKHFICBLCGELFEIAA.uhc0%40rz.uni-karlsruhe.de"
  17        TITLE="[IRCServices] Services Suggestion - NickServ">markh at eurodltd.co.uk
  18        </A><BR>
  19     <I>Fri Feb 23 00:17:01 PST 2001</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="001479.html">AW: [IRCServices] Services Suggestion - NickServ
  22 </A></li>
  23         <LI>Next message: <A HREF="001481.html">AW: [IRCServices] Services Suggestion - NickServ
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#1480">[ date ]</a>
  27               <a href="thread.html#1480">[ thread ]</a>
  28               <a href="subject.html#1480">[ subject ]</a>
  29               <a href="author.html#1480">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>&gt;<i> I do not see your point. I do not think, that services should
  35 </I>&gt;<i> handle causalities
  36 </I>&gt;<i> of what possible JavaChat daemons may have done to your network.
  37 </I>&gt;<i> If you really cannot live with that specific daemon, you will
  38 </I>&gt;<i> need to recode services
  39 </I>&gt;<i> to live with it, and not enforce me to compile a code specific to
  40 </I>&gt;<i> your network.
  41 </I>
  42 This issue is not specific to my network. The most common Java client I see
  43 is Jirc over which only the writers have control over and is installed by a
  44 number of users covering a number of channels on a number of networks hence
  45 my suggestion for the benefit of all networks.
  46
  47 It was merely a suggestion and I have every intention of doing it myself for
  48 the benefit of my users which ultimately is the aim of improvements in
  49 services and ircd coding.
  50
  51 &gt;<i> First of all, that nickname event may be solved in your javachat daemon.
  52 </I>&gt;<i> You should be able to modify it to either
  53 </I>&gt;<i> - not suggest a default nick
  54 </I>
  55 If you have access to the code to change it yes. Otherwise no. Since most
  56 Java clients in use are not open source changing them is not an option. I do
  57 not have any desire to code one myself but see no benefit in avoiding their
  58 traffic to the network.
  59
  60 &gt;<i> - change the suggestion to Guest* and not JavaGuest*
  61 </I>&gt;<i> Or, you can use another daemon.
  62 </I>
  63 These are down to individual user preferences. For example a #Millennium
  64 channel use MilGuest as their Jirc guest nick. In the same way I have no
  65 control over what client someone uses to connect to the network I cannot
  66 control which other interfaces a channel owner will use to bring users to
  67 his or her channel nor should I. By the same token if it is beneficial to
  68 more than one user it seems worth the effort to support this new wave of
  69 client and to remove the load on channel owners and opers managing the guest
  70 nicks becoming registered.
  71
  72 &gt;<i> And second, that condition is not a case services should handle
  73 </I>&gt;<i> in my opinion.
  74 </I>
  75 Everyone is entitled to that but you seem to be under the impression this
  76 was specific to my network. It is not otherwise I would handle it locally
  77 and not suggest an improvement that may benefit others.
  78
  79 IRC is constantly evolving with a number of alternatives having appeared but
  80 none yet to really compete with it. The type of user we see these days is
  81 increasingly of the layman breed rather than the original more technical
  82 users of IRC so tend to use easier programs. Java interfaces are something
  83 which are accessible on a number of platforms and are being integrated into
  84 other programs as an alternative to coding an IRC client. Rather than ignore
  85 these users, I hope that networks can evolve to accomodate them. As they
  86 become regular users they will migrate to a dedicated IRC client program at
  87 some stage.
  88
  89 Obviously there is a line between what should be client side, what should be
  90 server side and what should be in services. But I do not think we should we
  91 ignore the grey areas just to stay in black and white.
  92
  93
  94 Mark.
  95 CTCP Networks.
  96
  97
  98
  99 </PRE>
 100
 101 <!--endarticle-->
 102     <HR>
 103     <P><UL>
 104         <!--threads-->
 105         <LI>Previous message: <A HREF="001479.html">AW: [IRCServices] Services Suggestion - NickServ
 106 </A></li>
 107         <LI>Next message: <A HREF="001481.html">AW: [IRCServices] Services Suggestion - NickServ
 108 </A></li>
 109          <LI> <B>Messages sorted by:</B>
 110               <a href="date.html#1480">[ date ]</a>
 111               <a href="thread.html#1480">[ thread ]</a>
 112               <a href="subject.html#1480">[ subject ]</a>
 113               <a href="author.html#1480">[ author ]</a>
 114          </LI>
 115        </UL>
 116
 117 </body></html>