software/!RELEASES/ircservices/achurch.org/services/lists/ircservices/2001/001479.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> AW: [IRCServices] Services Suggestion - NickServ
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=AW%3A%20%5BIRCServices%5D%20Services%20Suggestion%20-%20NickServ&In-Reply-To=LPBBJLDCHCNGAKLLJFKNOECPCEAA.markh%40eurodltd.co.uk">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="001478.html">
  11    <LINK REL="Next"  HREF="001480.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>AW: [IRCServices] Services Suggestion - NickServ</H1>
  15     <B>Yusuf Iskenderoglu</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=AW%3A%20%5BIRCServices%5D%20Services%20Suggestion%20-%20NickServ&In-Reply-To=LPBBJLDCHCNGAKLLJFKNOECPCEAA.markh%40eurodltd.co.uk"
  17        TITLE="AW: [IRCServices] Services Suggestion - NickServ">uhc0 at rz.uni-karlsruhe.de
  18        </A><BR>
  19     <I>Thu Feb 22 23:43:00 PST 2001</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="001478.html">[IRCServices] Services Suggestion - NickServ
  22 </A></li>
  23         <LI>Next message: <A HREF="001480.html">[IRCServices] Services Suggestion - NickServ
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#1479">[ date ]</a>
  27               <a href="thread.html#1479">[ thread ]</a>
  28               <a href="subject.html#1479">[ subject ]</a>
  29               <a href="author.html#1479">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>Hello;
  35
  36 &gt;<i> We have a number of users that come from Java clients. As is the nature of
  37 </I>&gt;<i> many java based IRC interfaces they have a &quot;default&quot; nickname and use an
  38 </I>&gt;<i> incrementing numerical suffix to maintain some form of unique
  39 </I>&gt;<i> nicknames.  A
  40 </I>
  41 Nice, but we don't have such servers.
  42
  43 &gt;<i> majority of users of this service tend to use the default despite a number
  44 </I>&gt;<i> of encouragements to choose their own nickname first. It was &quot;interesting&quot;
  45 </I>&gt;<i> to see how many people actually joined a chat called TypeYourNameHere...
  46 </I>&gt;<i> hehe.
  47 </I>&gt;<i>
  48 </I>
  49 Possibly yes. Or you modify the java client, that it does not show a default
  50 nickname, but only set an IDENT for a nick. That way, users WILL have to chose
  51 a realistic nickname.
  52
  53 &gt;<i> The problem comes when one of these visitors registers the nickname. E.g.
  54 </I>&gt;<i> JavaGuest. The next JavaGuest coming in with that name will get forcibly
  55 </I>&gt;<i> changed to Guestnnn by Nickserv.
  56 </I>&gt;<i>
  57 </I>
  58 And ?
  59
  60 &gt;<i> NS now seems to correctly prevent the registration of it's own internal
  61 </I>&gt;<i> Guest names and there appears to be an appropriate flag to detect that a
  62 </I>&gt;<i> nick is &quot;guested&quot; so working from this base, I see two possible solutions:
  63 </I>&gt;<i>
  64 </I>
  65 Solutions for a possible Java web interface your network uses ?
  66 Is that case so common, that it has to be solved globally ?
  67 What if I start demanding additions for my network only ?
  68
  69 &gt;<i> 1) The current NS supports suspension and forbidding of
  70 </I>&gt;<i> nicknames. Add a new
  71 </I>&gt;<i> state that does not forbid the use of the nickname but forbids
  72 </I>&gt;<i> registration
  73 </I>&gt;<i> of it. This however would be limited in application since each name
  74 </I>&gt;<i> generation by the JavaChat program would have to be set to this status
  75 </I>&gt;<i> creating a human workload that services is largely designed to remove.
  76 </I>&gt;<i>
  77 </I>&gt;<i> 2) Add in support for multiple user defined &quot;guest&quot; nickname types. This
  78 </I>&gt;<i> way, anyone whose nick is say JavaChatnnnn could be handled by
  79 </I>&gt;<i> the same code
  80 </I>&gt;<i> which handles services native guest names. Although probably easier as a
  81 </I>&gt;<i> configuration file change (as with the native current guest prefix), a
  82 </I>&gt;<i> registration mechanism with NS would be preferable. For the purpose of NS
  83 </I>&gt;<i> processing it could maybe use the new status value described above but
  84 </I>&gt;<i> merely stores a prefix in the database rather than an explicit
  85 </I>&gt;<i> nickname and
  86 </I>&gt;<i> the nick be flagged to be processed as a guest nick type. Maybe a new
  87 </I>&gt;<i> command /NS REGISTERGUEST &lt;JavaChatPrefix&gt; &lt;PrefixOwnerEmail&gt;.
  88 </I>&gt;<i>
  89 </I>
  90 I do not see your point. I do not think, that services should handle causalities
  91 of what possible JavaChat daemons may have done to your network.
  92 If you really cannot live with that specific daemon, you will need to recode services
  93 to live with it, and not enforce me to compile a code specific to your network.
  94
  95 First of all, that nickname event may be solved in your javachat daemon.
  96 You should be able to modify it to either
  97 - not suggest a default nick
  98 - change the suggestion to Guest* and not JavaGuest*
  99 Or, you can use another daemon.
 100
 101 And second, that condition is not a case services should handle in my opinion.
 102
 103 &gt;<i>
 104 </I>&gt;<i> Mark.
 105 </I>&gt;<i> CTCP Networks.
 106 </I>&gt;<i>
 107 </I>
 108 Regards;
 109 yusuf
 110
 111 ----------------------------------------------------------------------
 112 |<i> Yusuf Iskenderoglu                | You get to meet all sorts,     |
 113 </I>|<i> eMail - <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">uhc0 at rz.uni-karlsruhe.de</A>  | in this line of work...        |
 114 </I>|<i> eMail - <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">s_iskend at ira.uka.de</A>       |                                |
 115 </I>|<i> ICQ UIN : 20587464 \ TimeMr14C    |                                |
 116 </I>----------------------------------------------------------------------
 117
 118
 119
 120
 121
 122
 123 </PRE>
 124
 125 <!--endarticle-->
 126     <HR>
 127     <P><UL>
 128         <!--threads-->
 129         <LI>Previous message: <A HREF="001478.html">[IRCServices] Services Suggestion - NickServ
 130 </A></li>
 131         <LI>Next message: <A HREF="001480.html">[IRCServices] Services Suggestion - NickServ
 132 </A></li>
 133          <LI> <B>Messages sorted by:</B>
 134               <a href="date.html#1479">[ date ]</a>
 135               <a href="thread.html#1479">[ thread ]</a>
 136               <a href="subject.html#1479">[ subject ]</a>
 137               <a href="author.html#1479">[ author ]</a>
 138          </LI>
 139        </UL>
 140
 141 </body></html>