On Fri, 2007-03-09 at 09:03 -0500, Michael Poole wrote: > > 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? > > I would like to remove overlapped G-lines, too. I'll have to make > implementing trie code a higher priority -- but some of the ideas > apply separately. My thought was that G-line(-like) entries would be > indexed by target, and each target would have both a global and a > local rule. If the local rule is set, it takes precedence over the > global one (only for that target mask). G-lines for * only update the > global rule; G-lines for any other target only update the local rule.
Makes sense... > I have been calling the exists-until time on the entry its "lifetime" > rather than its "expiration". When we get a G-line for a target and > local-ness that already exists: the incoming lastmod can be older, the > same or newer than the existing one; and the incoming lifetime can be > longer, the same or shorter than the existing one. Probably a better terminology than what I was using :) > Also: I use "replace" because a fairly common feature request is to be > able to change the G-line message when activating a G-line that was > previously inactive. If we're going to be changing the G-line code, > we might as well provide that feature once we're happy with the rules > for updating other fields. That's one of my goals, too. I'm thinking about ways of changing the gline syntax to allow more flexibility on setting and changing things. > <Entrope> things i forgot to say in my email: > <Entrope> glines with no listed lifetime have lifetime == expiration > <Entrope> and, as is (mostly) done now, incoming glines with no listed > lastmod are treated as being more recent than any existing gline > <Entrope> and i'd suggest that we don't keep a flag for deactivated > glines: if we get a [EMAIL PROTECTED], we set the expiration (but not > lifetime) to be at or before the current time I'd considered that as well, but I'm wondering if we want to allow a G-line to be deactivated, then reactivated with the same options it had before. If we reset the expiration time like this, my command syntax will require us to respecify both the expiration time and the G-line reason... BTW, is this a change we should stick into .13, or are you comfortable with development of this in .12.pre10? -- 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
