As most of us know, its generally not possible to detect the combination of ops/voice on a channel member, unless present from the time those modes were combined on. However, information might later be availible which could establish whether or not a client is voiced, such as a /names taken after the client has been deopped.
I'm going to suggest a couple of changes to help with the problem: 1 - Whenever a command such as /who or /names is issued, if any data is presented that conflicts with the client's idea of "reality", the client should update itself from the new data. (This means /names and /who (as well as /whois) could be used to fix syncronization problems if the user was aware of them. This also helps with another syncronization problem, those networks which provide switchable host masking for users... 2 - Whenever a obvious inconsistancy is detectable to the client, the client should request information from the server which could resolve that inconsistancy (ie, an apparently -v user talking on a +m channel) 3 - Whenever $ischanvoice() is called, and the voice status for a client is unknown, if there is the possibility of new information being available (ie the client in question is no longer a channel operator), the client should return -1, but afterwards query the server for information which will accurately determine if a client is voiced. Updating the cache on the basis of any new information also solves another problem, inconsistancies caused by user error or new "features" in the server (such as toggleable hostmasking) can be easily and in some cases, automatically corrected. Also, an "uncertian" state is needed for $ischanop() as well, for servers which offer hidden channel op status. This would have to be implemented in conjunction with server capability code most likely. -- Josh Rollyson GPG 0x143B66BF [EMAIL PROTECTED] _______________________________________________ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
