Re: [EPIC]notify interval proposal
On Monday 03 February 2003 10:32 pm, Jeremy Nelson wrote: > It seems that the current compromise solution seems to be acceptable to a > large number of people: [snip compromise that seems to be acceptable to a large number of people] This is fine by me. I would support intervals of less granularity than 60 seconds, and the obvious extension of that is that whatever limits the client sets, the user is able to circumvent it trivially; thus config.h is a reasonable place to put it. I would prefer it there rather than not limiting the /set, for a couple of reasons; - Someone is going to /set notify_interval 1 and wonder why they lag / the server keeps disconnecting them. - It's preferable to warn users exactly what they're doing, for that reason and others, and a comment above the option in config.h would be a reasonable way to achieve that. Regards, Edward. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
nsx said: >> Yes, I am campaigning for both better precision, and a change of the lower >> notify interval limit. I suppose they sort of go hand in hand, since to >> either abolish or lower the lower limit, you'd probably need to provide >> better precision anyway. Kev said: >Personally, I don't see the problem with the first part--increasing the >precision. As for a lower limit, I would strongly suggest that it should >not be less than 30 seconds. It seems that the current compromise solution seems to be acceptable to a large number of people: * Remove NOTIFY stuff from the "top_of_minute" timer, into a second timer. * Allow user to modify timeout interval of that second timer via /SET NOTIFY_INTERVAL * Add a #define in config.h which will set an absolute minimum value of /SET NOTIFY_INTERVAL, so that the user can be assured that a script will not set a value lower than they wish to have. * The default value of this #define will be 60 for backward compatability. Of course with every compromise, not everybody got everything they wanted, but this seems to be very much in the middle of what everybody hoped for. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
> Yes, I am campaigning for both better precision, and a change of the lower > notify interval limit. I suppose they sort of go hand in hand, since to > either abolish or lower the lower limit, you'd probably need to provide better > precision anyway. Personally, I don't see the problem with the first part--increasing the precision. As for a lower limit, I would strongly suggest that it should not be less than 30 seconds. -- Kevin L. Mitchell <[EMAIL PROTECTED]> ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On Mon, Feb 03, 2003 at 12:48:30PM +, Edward Brocklesby wrote: > Correct me if I'm wrong, but the impression I got from nsx on IRC and in his > mail was that he wanted a notify interval of less than 60 seconds, which is > what I'm discussing here. > > I wouldn't have any problem with allow more than +-60 second precision. > Yes, I am campaigning for both better precision, and a change of the lower notify interval limit. I suppose they sort of go hand in hand, since to either abolish or lower the lower limit, you'd probably need to provide better precision anyway. -- John ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On Sun, Feb 02, 2003 at 02:08:44PM -0500, Ben Winslow wrote: > Edward Brocklesby wrote: > [snip] > > and I'm not likely to talk to someone who's here for 30 seconds and then > > gone again > [snip] > > > > -larne. > > Try using dial-up service over the US's PSTN. ;) Nothing RFI chokes, modem strings, and harassment of the local telco can't fix ;) ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On Mon Feb 03, 2003; 12:48PM + Edward Brocklesby propagated the following: > On Monday 03 February 2003 7:27 am, [EMAIL PROTECTED] wrote: > > having finer granularity doesn't necessarily mean that it would be used to > > have notify interval shorter than 60 seconds. it would also allow notify > > intervals of, for example, 90 seconds. there still might be a lower limit > > of 60 seconds. > > Correct me if I'm wrong, but the impression I got from nsx on IRC and in his > mail was that he wanted a notify interval of less than 60 seconds, which is > what I'm discussing here. > You are correct. Personally I'd like to see this tuneable down to 20-30 seconds (at lowest). It would be nice to have a more precise notify level. I also think that if servers find this load burdensome than they should either add code to disconnect users who do this or add WATCH support, both of which are fairly trivial things to do. > I wouldn't have any problem with allow more than +-60 second precision. > > Regards, > Edward. > ___ > List mailing list > [EMAIL PROTECTED] > http://epicsol.org/mailman/listinfo/list -wd -- chip norkus; unix geek and programmer; [EMAIL PROTECTED] "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On Monday 03 February 2003 7:27 am, [EMAIL PROTECTED] wrote: > having finer granularity doesn't necessarily mean that it would be used to > have notify interval shorter than 60 seconds. it would also allow notify > intervals of, for example, 90 seconds. there still might be a lower limit > of 60 seconds. Correct me if I'm wrong, but the impression I got from nsx on IRC and in his mail was that he wanted a notify interval of less than 60 seconds, which is what I'm discussing here. I wouldn't have any problem with allow more than +-60 second precision. Regards, Edward. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On 2003/02/02 15:26:55 +, Edward Brocklesby wrote: > While this is a somewhat.. hotly debated topic on IRC, and I don't want to > start that here, I will add my opinion; which is that I can't see a valid > reason for a notify interval of less than 60 seconds. However, on the other > hand: a) I don't use /notify myself anyhow; b) I tend to be very patient, and > I'm not likely to talk to someone who's here for 30 seconds and then gone > again, so maybe my viewpoint here isn't a typical one. having finer granularity doesn't necessarily mean that it would be used to have notify interval shorter than 60 seconds. it would also allow notify intervals of, for example, 90 seconds. there still might be a lower limit of 60 seconds. lanzz -- $_=q<$_=q<,>;s/,/$_/;print;>;s/,/$_/;print; ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
Edward Brocklesby wrote: [snip] > and I'm not likely to talk to someone who's here for 30 seconds and then > gone again [snip] > > -larne. Try using dial-up service over the US's PSTN. ;) -- Ben msg00259/pgp0.pgp Description: PGP signature
Re: [EPIC]notify interval proposal
On Thursday 30 January 2003 8:17 pm, john wrote: [notify interval should be shorter] While this is a somewhat.. hotly debated topic on IRC, and I don't want to start that here, I will add my opinion; which is that I can't see a valid reason for a notify interval of less than 60 seconds. However, on the other hand: a) I don't use /notify myself anyhow; b) I tend to be very patient, and I'm not likely to talk to someone who's here for 30 seconds and then gone again, so maybe my viewpoint here isn't a typical one. I would be concerned about the load placed on the server by this; yes, mIRC might use a smaller delay, but that isn't excuse nor justification for doing it in EPIC, and I wouldn't like to see this being used to support a change in EPIC. [I'm not trying to start an argument here, only put my view across.] -larne. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
On my part, I would also add that although EPIC does its best never to allow any RFC breakage (in other words: users who really want to send a PRIVMSG in an ON MSG cannot do so without a certain amount of hassle), there is no set standard pertaining to notify checking. On all non-RFC issues, EPIC has always been the client that allowed the users maximum flexibility an "no limitations". Therefore I think that the users who SET NOTIFY_INTERVAL 1 can only blame themselves, as the help files would surely contain a strong discouragement towards such settings. That has always been the way to do things, and I myself see no reason why EPIC should impose limits this time. -- Roses are red, violets are blue, some poems rhyme, but this one doesn't. |\ /| \~~~/ \~~~/ WWW: http://none :( | \/ | /\ > < \~/ >
Re: [EPIC]notify interval proposal
I'd assume that most users who would set notify_interval, would know what they're doing, but I may be wrong. I can certainly see the scenario in which a new user who likes to experiment, unsuspectingly sets this to what most would consider an unreasonable value (such as 1), but I also assume even the most unfamiliar user to epic would be more cautious than that, and realize that tinkering with things without realizing their purpose can have consequences. Nonetheless, I can certainly see why Jeremy sees it prudent to enforce a lower limit here. But at the very least, I would like to see what I would consider a more reasonable lower limit (20-30 seconds, perhaps). I wouldn't consider that too unreasonable since the majority of the IRC population is probably mIRC clients, and they all use a 30 seconds interval. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
Normally I would not follow up to a request for discussion, but nsx asked me to share why I believe in the status quo. The entirity of this message is not a statement of policy or rules or anything of the sort with regard to epic. It simply states my personal opinions as an epic user, and the reasoning that prompted this discussion in the first place. Nsx said: - >>From what I can tell, epic doesn't allow you any more precision than minutes >in the notify interval, and it refuses to accept a value of under a minute. For most of epic's life, the main focal point of everything that happens is the io() function, which i refer to as "The Looper". io() has had its share of issues, particularly how everything is hardcoded into it, and that limits flexibility and generalness. One of the things that was hardcoded into the looper was "top of the minute" processing. At the top of every minute, epic does various housekeeping duties: 1) Checks your mail 2) Throws /on timer 3) Does your notifies 4) Updates the clock (on the status bar) Previously, EPIC always and only ever performed these duties at the top of each minute. The /SET NOTIFY_INTERVAL value was added as a way for some users, who felt that doing notifies once a minute was far too frequently and imposed too much of a burden on the server, to rachet down the frequency of their notifies. Even though the unit used was a second, the granularity was always measured in minutes, since the notifies only ever happened at most once a minute anyways. Recently, this changed somewhat. When I rewrote the /timer system, I was able to remove the "top of the minute" processing from the looper and instead make it a regular, recurring, system timer. Because it is now a regular, recurring, system timer, it is no longer necessarily hardcoded to happen only at the top of every minute. Nsx has pointed out that this has opened up the viability of discussing whether or not we should remove notify handling from the "top of the minute" processing and make it a second, separate regular, recurring, system timer with its own timeout and have it work independantly of the "top of the minute" timer. The reason why notify is done at most once a minute even now should be clear; it is done from within a timer that happens at most once a minute. The question then becomes, should we remove notify handling from this timer; make it operate under its own timer; and have the timeout be controlled by /SET NOTIFY_INTERVAL. This raises sticky issues however. As we all know, the server imposes flood control upon the user, generally allowing at most one protocol command per 2 seconds. Excessive commands causes the client to be penalized and eventually disconnected. In general, it would be a violation of user's expectations that changing a /SET would cause them to get disconnected from the server due to reasons that they cannot personally understand (ie, if you /set notify_interval 1, you will be disconnected eventually, the user wouldn't understand why, though). So there perhaps should be some lower limit on the number of seconds between each notify event, *even though a user may wish to do it more frequently*. The question is what that minimum number of seconds should be. My personal opinion is still that 60 seconds is best, to be most kind to the server. Notify imposes a not-small burden on the server, and much pain and suffering is caused by clients doing TOO MANY notifies, not too few... And that is my opinion. I am not speaking as a coder, but as a fellow user. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]notify interval proposal
I've been frustrated for awhile with the fact that epic doesn't allow you to easily modify the notify interval. >From what I can tell, epic doesn't allow you any more precision than minutes in the notify interval, and it refuses to accept a value of under a minute. There's a couple of things I'd like to see changed in epic's notify system. First off, I'd like to see more precision; I'd prefer to be able to set this value in seconds, not just in minutes. Secondly, I'd like to see the lower limit completely abolished. The /timer command has no lower limit, why should the notify system? While power users may be able to to change this behavior by making their own modifications to epic's source code, it is mildly annoying, and not everybody can do this. I'd like to see epic's notify system behave the way I've described by default. Please send back your feedback on this issue, whether you're in agreement, disagreement, or even if you're ambivalent towards the issue. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
