On 25-Jun-00 17:18:43, Ian Kumlien <[EMAIL PROTECTED]> found a keyboard and wrote
about:
[amirc] Re: AmIRC 3.5 /mode bug.
[-SNIP-]
> That's exessive bandwidth usage imho..
Well, is it really? Its already done whenever other modes +/-v and +/-o are
done, why not when other modes are set on users?
And as far as bandwith usage comes into play its not a lot of imho, and
certainly far from excessive.
/NAMES dont give that much text back, and since no one complains about
excessive bandwith usage on mode changes like +/-o and +/-v i wouldnt think
it would cause more load to have it do /NAMES when modes are changed on
users.
Furthermore when modes are changed on users in channels that means in 99% of
the cases that they have been prefixed with a special char in the userlist
which wont appear unless a /NAMES is called.
Now, this would only happen on IRCd's that support it and thus you would
have no changes whatsoever for users who dont care about it like yourself.
[-SNIP-]
> well it shows +n and +t (No messaging and topic protection) it just
> resolves the known modes.
Not quite true.
�Mode� Current modes for #OxOnet: no messaging, +r, topic protection,
or raw as it is presented from the server
:irc.oxonet.com 324 ShadowMaster #OxOnet +nrt
AmIRC knows these modes as it gets told whenever you enter a channel.
It wouldnt be more trouble than having AmIRC grab the mode string raw from
the server instead of making a mess and using only the ones AmIRC have an
internally defined name for.
[-SNIP-]
> ftp://ftp.vapor.com/pub/amirc/info/rfc1459.txt - The IRC protocol.
>
> That is what AmIRC supports, Nothing else.
False statement. AmIRC support dozens of features not specified in the 9
year old IRC protocol as put forth by Jarkko.
[-SNIP-]
> UltimateIRCd is not a standard and the usage of +/-h isn't standard
> etc, There has been many simular discussions and the answer has always
> been that amirc will only support the standard IRC protocol.
Hardly ANY ircd out there today is standard by the 9 year old protocol. Its
something called evolution. There have been many similiar discussions where
people who apparently have no other objective by discussing issues that
would improve AmIRC for those who use it and apparently would not affect
themselves just for the heck of it.
I think i have said this countless of times, and more than once to you
before. Why on earth should AmIRC not behave like more or less every other
IRC Client out there and instead of filtering away information from the user
actually output it to the user. Especially when it would in fact lessen the
load on AmIRC even though its not much, but apparently people belive it to
be enough to start crying out in rage once someone asks for features they
personally dont see the need for and seem to fear will cause AmIRC to start
using up another meg of their precious memory or eat up a lil second of CPU
time every once in a while.
Anyhows, AmIRC have added a few features to accomodate f ex IRCnet's IRCd
which do not follow the RFC either. Channel Mode +I (Auto Invites on IRCnet
and No Invites on some other ircd's) are supported aswell as Channel Mode +e
(Excempt bans). AmIRC choose to support silence which isnt specified in the
RFC but have been supported by AmIRC for as long as i can remember.
There are many other features that i dont bother listing that are not
specified in the RFC by Jarkko but still are supported by AmIRC.
Also as a small note. +/-h is a widly used mode for designating HalfOp's.
Both by UltimateIRCd, UnrealIRCd and others. I cannot speak for Unreal but
UltimateIRCd have a registered userbase of 160+ server administrators on a
wide range of networks, apart from having a current average of between
500-1000 downloads per stable release and still growing.
As a second small note you state that:
"the answer has always been that amirc will only support the standard IRC protocol."
Which is totally false. Read above and i will also point out the just
between 3.4 and 3.5 there where changes made to AmIRC to accomodate so
called non RFC standard features (Silence) and a less recent change the
addition of color support. Just because YOU concluded with that answer dont
try and force everyone around you to share that belive.
> (you are however free to write plugins... =))
I shouldnt have to. Its something that should be supported by default
instead of filtering stuff away.
Again, even the most basic IRC clients like ircII does not filter stuff out:
*** Mode change "+h WhoMe" on channel #ShadowRealm by ShadowMaster
Why shouldnt an advanced IRC Client like AmIRC?
Sides, plugins requires knowledge of C unlike simple yet powerfull internal
script languages. Most IRC Clients support such scripting languages, Perl,
TCL, mIRC Scripting... yes i know AmIRC have arexx, but AmIRC dont have the
ability to have arexx capture and handle the incoming text from the server.
If i have been inaccurate on some points please do forgive me. I try not to
write mails a 5 am, but i have to admitt replies of this sort when people
ask for feature and someone decides to make some sort of ruling on it when
they have no right to tends to anger me somewhat.
Its ok to voice an opinion, but please dont throw inaccurate and false
statements around like this. I belive its up to Olli and Jamie to decide
wheter or not something should be supported or not, and not up to you.
--
Yours Sincerely
Thomas J. Stensas (HAMLET/ShadowMaster @ IRC)
<sb>
Network Administrator Village IRC Network - (http://www.VillageIRC.net/)
Server Administrator Exodus IRC Network - (http://www.ExodusIRC.net/)
Head Of Development ShadowRealm Creations - (http://www.Shadow-Realm.org/)
Author And Project Administrator UltimateIRCd -
(http://www.Shadow-Realm.org/ultimate.html)
IBM & M$ are trademarks; Amiga is a philosophy.
<sb>
A sense of humour is the difference between ambition and achievement.
___________________________________________________________________
AmIRC Mailing List - http://www.vapor.com/amirc/
AmIRC FAQ......: http://faq.vapor.com/amirc/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
