[IRCServices Coding] Mass memos

[M]

Trevor Talbot wrote:
> >> This is not spam, and should probably be only accessible by either
> >> Services Admins or Services OPs.  The intention is to announce 
> >> outages, important events, etc
> >
> > /os global <message>
> 
> That doesn't cover people who aren't online at the time.

Outages are generally transient. If they involve services, memoserv
would be just as useless as logon news and an /os global if they are
offline when a given user comes online. There are enough ways to warn
users of pre planned outages that will last some time including the
associated web site for the network. 

Let us say servies will be upgraded in an hour's time. Ignoring the fact
that we can do this in version 5 with zero effect on connected users,
whatever online system employed will only work for those users connected
at that time. If services was restarted a few times with memos, a number
of users would end up with an "inbox" of pointless notices. /os global
would be the correct place to accounce such things. 

> > You did not ask a memo question that has an answer, you 
> made a feature
> > request. The nick prefix has nothing to do with memos.
> 
> He described a visibility problem as a reason for the feature 
> request.  
> He also described a nick linking issue while attempting to handle a 
> "mass memo" feature on his own.  While technically not questions, I 
> would think it was obvious that responses were desired in those 
> contexts.

This was covered in depth during my response.

> >> Frankly, logonnews is useless, and most of my users and 
> opers agree.
> >> It scrolls off too fast.  Ideally, it shoudl have a delay 
> to prevent 
> >> it being lost in the system notices on connection.  Maybe 
> a 10 second 
> >> delay beforee it flashes by, to give the user time to 
> connect, etc, 
> >> and then they might actually SEE it.
> >
> > That is hardly a services issue. The IRCd would be the place to add
> > false delays into the login process.
> 
> Logonnews is not part of the ircd's login process.

But since services uses the IRCd to issue it's messages, introduction of
delay's in the process is an IRCd issue, not a services one. If the IRCd
will not delay, services cannot.

> >> Most users I know don't tend to make a habit of readin gth ebacklog
> >> in their status windows when they connect to the network......
> >
> > Many users do not check memos on a regular basis either so spamming
> > via memoserv would just fill their memo box and they are 
> still are not 
> > guaranteed to be read. They could also add you to their 
> ignore list so 
> > your message would not get through in any case.
> 
> Memos generally have a much higher visibility than logonnews.  

Really? At logon, the notice of new memos is just as lost as logon news.


> You're 
> welcome to provide very thorough examples to the contrary, but you'll 
> be working against the tide of experience from a lot of 
> people on a lot 
> of different networks, apparently including Saturn.

Without examples supporting the original suggestion, there is no need to
provide contrary ones. 

Client configuration has a huge effect on visibility of any information
presented to the user and is beyond the scope of both IRCd and services.
No solution for memo notification or logon news (or indeed /os global)
will defeat client configuration.

M.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003