software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2003/002137.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] Mass memos
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Mass%20memos&In-Reply-To=2C31F186-CDEE-11D7-979C-0003938D6866%40mac.com">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="002135.html">
  11    <LINK REL="Next"  HREF="002716.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] Mass memos</H1>
  15     <B>M</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Mass%20memos&In-Reply-To=2C31F186-CDEE-11D7-979C-0003938D6866%40mac.com"
  17        TITLE="[IRCServices Coding] Mass memos">mark at ctcp.net
  18        </A><BR>
  19     <I>Thu Aug 14 14:38:24 PDT 2003</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="002135.html">[IRCServices Coding] Mass memos
  22 </A></li>
  23         <LI>Next message: <A HREF="002716.html">[IRCServices Coding] AKill suggestion
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#2137">[ date ]</a>
  27               <a href="thread.html#2137">[ thread ]</a>
  28               <a href="subject.html#2137">[ subject ]</a>
  29               <a href="author.html#2137">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>Trevor Talbot wrote:
  35 &gt;<i> Services issues the messages itself.  The only sense in which it uses
  36 </I>&gt;<i> the ircd is the same as for any other entity on the network: the ircd
  37 </I>&gt;<i> is a relay point.  Services' issuance of messages is not tied to any
  38 </I>&gt;<i> part of the ircd's login process, nor is it affected by any delays
  39 </I>&gt;<i> present there.
  40 </I>
  41 Merely issuing logonnews messages later in the process would be unlikely
  42 to make any difference to visibility.  The delay picked will likely
  43 still conflict with other incoming messages and likely relies on the
  44 user returning to the status window after whatever they fill the gap
  45 with prior to the message. Neither the IRCd nor services can accurately
  46 predict a point at which logon news would not be placed amid other
  47 messages so merely issuing it later will not solve the issue. It will
  48 merely put it into a different place during the process that users who
  49 do read it will not expect.
  50
  51 I originally assumed that the proposal was to force users to see it by
  52 pausing at that point (time delay or press any key style AKA telnet
  53 login notices) which would be an IRCd issue to support such a delay, not
  54 a services one. I would not support this system either since users
  55 generally want to get onto the network and chatting ASAP.
  56
  57 &gt;<i> Many people
  58 </I>&gt;<i> deal with large amounts of information, and so may notice the memo
  59 </I>&gt;<i> notification while unconsciously ignoring the login news (much like
  60 </I>&gt;<i> motds are ignored).  This is just speculation, of course.
  61 </I>
  62 I see what you are saying but disagree with the conclusion. It is not
  63 supported by the number of users who incorrectly identify for a nickname
  64 then are most surprised when they are &quot;guested&quot;. If they miss the
  65 failure notice, they are equally likely to miss the memoserv notice.
  66
  67 We only use logon news to announce important events so it is immediately
  68 obvious to people when it changes since there is normally nothing
  69 displayed at that point and the logon process looks different when it is
  70 displayed. Conversely, I have found a number of users (particularly
  71 newcomers) tend not to notice any message from memoserv since the
  72 message occurs at every logon and the pattern is so familiar to them
  73 they tend not to read the notice closely.
  74
  75 One thought does occur with the mention of MOTD, a client can issue this
  76 command to retrieve the message whenever they desire but they cannot do
  77 this with logon news (IRCops aside). Maybe the solution is not messing
  78 around with delays, but thinking of a new way to propagate this
  79 information. The quick way would of course be to allow /os logonnews
  80 list to all users. However, I favour keeping OperServ solely accessible
  81 to opers so would suggest &quot;NewsServ&quot; or similar as a way to allow end
  82 users to access current news on demand.
  83
  84 &gt;<i> Memo visibility is logically heightened by notification in other
  85 </I>&gt;<i> circumstances: nick changes, identification, etc.
  86 </I>
  87 IME, a great number of clients do not change nickname that often (if at
  88 all) and once identified tend to remain that way. IIRC, the new linked
  89 nick system, means that those that do tend to use multiple nicks do not
  90 have to identify for the change should it be so linked. Increasingly
  91 users use clients or additional scripts to automatically identify to
  92 services. The lack of user input into the process further decreases the
  93 notice a user will take of notices in response to identification etc.
  94
  95 &gt;<i> The best solution for this issue in general would be to have clients
  96 </I>&gt;<i> become &quot;information managers&quot;, where they could do things such as
  97 </I>&gt;<i> deciding if the motd or logonnews has changed since last connect,
  98 </I>&gt;<i> providing alerts if necessary, and so on.  The ircd and services would
  99 </I>&gt;<i> need to provide standard formats for this information.  Unfortunately
 100 </I>&gt;<i> we're nowhere near the point where this would be useful, especially
 101 </I>&gt;<i> considering the motd format has been standard for a very long
 102 </I>&gt;<i> time, and
 103 </I>&gt;<i> clients haven't done much with it.
 104 </I>
 105 ISTR at least a couple clients that tried to do something with it such
 106 as routing it to a separate window. There are ways to improve the
 107 process but as you suggest, they really require changes to both the IRCd
 108 (or at least adding some field(s) to the MOTD file) along with client
 109 changes.
 110
 111 /os global tends to suffer from visibility for similar reasons to logon
 112 news and other notices. However, IME sufficient users are aware of them
 113 and paste within channels so that those others see them. Similar occurs
 114 with logon news with it being discussed in channels in front of those
 115 users that do not bother to read it.
 116
 117 Much of the visibility is down to clients and the way that a user uses
 118 IRC. These things are beyond our control. However, approaching the
 119 writers of the more common clients/scripts may be the way to get the
 120 clients to perform better in this regard. Trapping the MOTD is
 121 relatively trivial for a client. For IRCServices at least, trapping
 122 logon news should be similarly trivial (given the format of the notice).
 123
 124
 125 Some IRCd packages are now implementing a dual MOTD system. At logon,
 126 the user is presented only with a &quot;short MOTD&quot; which can act as a
 127 &quot;headline&quot; that the user can further read by requesting the full MOTD.
 128 This helps reduce the redundant information passed to a user on connect
 129 and clean up the connection process as well as saving some bandwidth.
 130
 131 &gt;<i> In the meantime, things such as mass memos are useful for a variety of
 132 </I>&gt;<i> reasons.
 133 </I>
 134 I disagree. A mailing list would be a much better system to employ. It
 135 is opt in, creates no additional load on services and is more likely to
 136 be read than a memo by all users who subscribe. Couple this with web
 137 based information and you cover users who choose not to have the
 138 additional emails and do not read logon news.
 139
 140 A user unable to receive memos from friends because their memo box is
 141 full of messages about stuff on the network that they may have no
 142 interest in reading is not IMO a useful feature. As another poster
 143 mentioned, those users who visit infrequently are the most likely to
 144 suffer in this scenario. Filling the memo box via mass memos will for
 145 all practical purposes destroy the memoserv facility for a number of
 146 users.
 147
 148 Since a mass memo system should really be opt in, it is a simple matter
 149 for those interested to register their name in some manner with whoever
 150 wants to send mass memos, then the sender use a simple script to message
 151 only those users. This can be done without any required change to
 152 services and would not be subject to the problems in the OP's original
 153 script wrt linked nicknames. Such a script merely needs to parse the
 154 response from memoserv to automatically delete expired nicknames
 155 registered with the system.
 156
 157 M.
 158
 159 ---
 160 Outgoing mail is certified Virus Free.
 161 Checked by AVG anti-virus system (<A HREF="http://www.grisoft.com">http://www.grisoft.com</A>).
 162 Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003
 163
 164
 165 </PRE>
 166
 167 <!--endarticle-->
 168     <HR>
 169     <P><UL>
 170         <!--threads-->
 171         <LI>Previous message: <A HREF="002135.html">[IRCServices Coding] Mass memos
 172 </A></li>
 173         <LI>Next message: <A HREF="002716.html">[IRCServices Coding] AKill suggestion
 174 </A></li>
 175          <LI> <B>Messages sorted by:</B>
 176               <a href="date.html#2137">[ date ]</a>
 177               <a href="thread.html#2137">[ thread ]</a>
 178               <a href="subject.html#2137">[ subject ]</a>
 179               <a href="author.html#2137">[ author ]</a>
 180          </LI>
 181        </UL>
 182
 183 </body></html>