Re: LIST, service or fix of code

[Christophe Kalt <kalt@xxxxxxxxxxx>]

On Mar 19, Thomas Kuiper wrote:
| So here is my list pro/contra doing this via a service/LIST fix
| 
| Contra service:
| * Service sends only notice (doesnt give errors back if
| user isnt there anymore) - this means you will flood or at least
| use cputime of server if someone tries to get the full list.

*shrug*
this isn't a big deal.

| * You could do a easily DoS by doing
| /nick blah
| "/squery listservice list all"
| /nick blah2 (a second after this)
| "/squery listservice list all"
| /nick blah (a second after this)
| And the service gets paranoia. :(

it seems unlikely that a service would allow such a large
query.. one of the advantages of using a service is to be
able to make it smart enough to limit the scope of queries

| * A service seems not to be able to list channels
| (well, I wont like to use the 0x? that he gets all
| channel creation decreation, even if this would be
| the easiest way.

you don't suggest that the service send a "LIST" to the
local server for each query, do you?

| * Users in mIRC cant doubleclick on the text the service send
| back (hm, this is a lame contra, I probably remove
| it before clicking on send).

client issues are to be dealt at the client level.

| On the other hand this wont work if:
| pro:
| * The service has a match max, like
| "/squery listservice list linux*"
| -listservice@xxxxxxxxxxxxxxxxx To many matches, use web interface from ludd

exactly.

| * The service could have a delay of 500 ms (flood ctrl) before sending notices.

any service should limit the rate of outgoing traffic.
(cf doc)

| * The service can PRIVMSG nick!user@host instead of just the nick

it can NOTICE nick!user@host

| * The service could run on a descent server who doesnt count on traffic :P
| 
| Doing it via code:
| 
| Contra:
| * hm, more work "maybe"
| * Bigger cpu load on server
| * breaks RFC
| * Service can better interact with clients
| * needs to be _very_ selective what it should do before anyone codes it
* hard to change/extend
| 
| pro:
| * Easier to doubleclick in mIRC :)
| * easier to use
| 
| So I would like to vote this out or something :-)

a good service will be more popular (with users) than any ircd
hack.