There are some changes I'd like to make to the server<->server protocol for G-lines. The first is, since GNUWorld generates the lastmod parameter, I wish to do away with the 3-parameter form of G-line. This will hopefully simplify ms_gline() a bit. The second is to solve a problem with G-line, and will involve several modifications.
Let's start with a statement of the problem: If an oper issues a very long G-line on a domain, then deactivates that G-line, it is impossible to set a shorter G-line on the domain. The reason is simple: We have to keep the G-line in memory until it would have expired, so that servers that may have been split when the G-line was deactivated don't re-issue the G-line. The lastmod parameter was added in the last set of G-line changes in order to aid in making changes stick, but it does no good if the record goes away. The solution to this is to split the concept of "G-line" into two parts: the _ban_ and the _record_. We simply add a second expiration time to the G-line protocol message, just before the reason field. (ms_gline() uses parv[parc - 1], so this will be backwards-compatible.) This second expiration time will be the expiration time of the _record_, rather than the _ban_; the ban will expire on time by being automatically deactivated, but the record expiration time will be the latest expiration time ever issued for that particular G-line: The structure describing the G-line won't be destroyed until this record expiration time passes. This change will enable us to, in conjunction with the lastmod parameter, change the ban expiration time (or the G-line reason field) in whatever way we wish--lengthen it, shorten it, completely deactivate it, etc., without fear that the G-line will pop up in some intermediate form when some server reconnects to the network. We still won't be able to remove a G-line entirely, but we'll now be able to duplicate the *effect* of doing so, which should satisfy anyone that has to work extensively with G-lines. In addition to adding a second expiration time, I propose to remove the logic that deletes overlapping G-lines, if it's still present in the server. It just seems to cause too much trouble, and the G-lines will expire of their own accord anyway. We may also want to make changes to the way local G-lines work--maybe local G-lines should use a separate record, rather than having to be conjoined with the global G-line? But then we have to ask the question, how do we make locally-restricted changes to the G-line? Anyway, here are the thoughts for your review and discussion. Have fun :) -- Kevin L. Mitchell <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
