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
