1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices Coding] Mass memos
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=001001c361ed%24028267f0%246282edc1%40mark2k">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"002132.html">
11 <LINK REL=
"Next" HREF=
"002137.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices Coding] Mass memos
</H1>
16 <A HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Mass%20memos&In-Reply-To=001001c361ed%24028267f0%246282edc1%40mark2k"
17 TITLE=
"[IRCServices Coding] Mass memos">quension at mac.com
19 <I>Wed Aug
13 17:
28:
05 PDT
2003</I>
21 <LI>Previous message:
<A HREF=
"002132.html">[IRCServices Coding] Mass memos
23 <LI>Next message:
<A HREF=
"002137.html">[IRCServices Coding] Mass memos
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#2135">[ date ]
</a>
27 <a href=
"thread.html#2135">[ thread ]
</a>
28 <a href=
"subject.html#2135">[ subject ]
</a>
29 <a href=
"author.html#2135">[ author ]
</a>
34 <PRE>On Wednesday, Aug
13,
2003, at
15:
48 US/Pacific, M wrote:
36 ><i> Trevor Talbot wrote:
37 </I>>>>><i> This is not spam, and should probably be only accessible by either
38 </I>>>>><i> Services Admins or Services OPs. The intention is to announce
39 </I>>>>><i> outages, important events, etc
41 </I>>>><i> /os global
<message
>
43 </I>>><i> That doesn't cover people who aren't online at the time.
45 </I>><i> Outages are generally transient. If they involve services, memoserv
46 </I>><i> would be just as useless as logon news and an /os global if they are
47 </I>><i> offline when a given user comes online. There are enough ways to warn
48 </I>><i> users of pre planned outages that will last some time including the
49 </I>><i> associated web site for the network.
51 I agree with you on the specific case of outages, but I was speaking
54 >>>><i> Frankly, logonnews is useless, and most of my users and opers
55 </I>>>>><i> agree. It scrolls off too fast. Ideally, it shoudl have a delay
56 </I>>>>><i> to prevent it being lost in the system notices on connection.
57 </I>>>>><i> Maybe a
10 second delay beforee it flashes by, to give the user
58 </I>>>>><i> time to connect, etc, and then they might actually SEE it.
60 </I>>>><i> That is hardly a services issue. The IRCd would be the place to add
61 </I>>>><i> false delays into the login process.
63 </I>>><i> Logonnews is not part of the ircd's login process.
65 </I>><i> But since services uses the IRCd to issue it's messages, introduction
66 </I>><i> of delay's in the process is an IRCd issue, not a services one. If the
67 </I>><i> IRCd will not delay, services cannot.
69 Services issues the messages itself. The only sense in which it uses
70 the ircd is the same as for any other entity on the network: the ircd
71 is a relay point. Services' issuance of messages is not tied to any
72 part of the ircd's login process, nor is it affected by any delays
75 >>>><i> Most users I know don't tend to make a habit of readin gth ebacklog
76 </I>>>>><i> in their status windows when they connect to the network......
78 </I>>>><i> Many users do not check memos on a regular basis either so
79 </I>>>><i> spammingvia memoserv would just fill their memo box and they are
80 </I>>>><i> still are not guaranteed to be read. They could also add you to
81 </I>>>><i> their ignore list so your message would not get through in any case.
83 </I>>><i> Memos generally have a much higher visibility than logonnews.
85 </I>><i> Really? At logon, the notice of new memos is just as lost as logon
88 Yes, but this a psychological issue, not a logical one. Many people
89 deal with large amounts of information, and so may notice the memo
90 notification while unconsciously ignoring the login news (much like
91 motds are ignored). This is just speculation, of course.
93 Memo visibility is logically heightened by notification in other
94 circumstances: nick changes, identification, etc.
96 ><i> Client configuration has a huge effect on visibility of any
97 </I>><i> information presented to the user and is beyond the scope of both IRCd
98 </I>><i> and services. No solution for memo notification or logon news (or
99 </I>><i> indeed /os global) will defeat client configuration.
101 The best solution for this issue in general would be to have clients
102 become
"information managers
", where they could do things such as
103 deciding if the motd or logonnews has changed since last connect,
104 providing alerts if necessary, and so on. The ircd and services would
105 need to provide standard formats for this information. Unfortunately
106 we're nowhere near the point where this would be useful, especially
107 considering the motd format has been standard for a very long time, and
108 clients haven't done much with it.
110 In the meantime, things such as mass memos are useful for a variety of
121 <LI>Previous message:
<A HREF=
"002132.html">[IRCServices Coding] Mass memos
123 <LI>Next message:
<A HREF=
"002137.html">[IRCServices Coding] Mass memos
125 <LI> <B>Messages sorted by:
</B>
126 <a href=
"date.html#2135">[ date ]
</a>
127 <a href=
"thread.html#2135">[ thread ]
</a>
128 <a href=
"subject.html#2135">[ subject ]
</a>
129 <a href=
"author.html#2135">[ author ]
</a>
projects / irc.git / blob