Another long one: On Sunday 02 March 2003 23:36, Kurt Bigler wrote: > on 3/2/03 7:13 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
<snip> > > ----- Original Message ----- > > From: "Kurt Bigler" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, March 01, 2003 10:46 PM > > Subject: Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision) > > > >> on 2/28/03 3:42 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > >>> On Friday 28 February 2003 18:09, Kurt Bigler wrote: > >>>> on 2/28/03 12:44 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: <snip> > >> As I see it, the '-' option makes any value in the first field > >> irrelevant. > > > > Yup. And the second field too. > > No not the second field. You're right. Don't know what I was thinking! <snip> > > >> The only reason I could think for introducing a _related_ flag might be > >> to provide a way to show the popup list but default it to the blank item > >> at the top. > > > > A blank first field should actually (in my mind) do this too. Just add a > > record with the necessary group identifier in the modifier field and > > insert a blank first field. Instant no default. Of coarse, this doesn't > > work yet either... > > > > Does that sound right? > > I don't think it is necessarily a good thing. A blank field to me, and as > gone over above (and in the following, below) means turn off all the > feature, which means there IS no popup list. No, a blank field means there is no default (in my mind). In the case of hidden fields, this means that there is no hidden field either, but in the case of drop downs, it'll just mean that we default to a blank field. I think some system account users may possibly find that useful. > So therefore you would need a > separate option to cause the popup list to show without a default. > > This makes me think we almost want a specific option just to say whether > the popup list is present. Right now it is implied by the other options, I > think. That's good as long as we don't end up making any contradictory > changes. I certainly can't think through all the options in my head > anymore. But I think with the unnecessary ones gone it will be easier, and > we can revisit it. > > Note: I added a suggestion below that might take care of this issue. (The > two little indented tables about 2/3 of the way down, just so you can > recognize when you get there.) > > Would it be good to bounce around a very reduced form of documentation > until everything settles? Probably. Once I get this next patch out with the strtok() replacement I'll hopefully be able to write up a short help doc. The options will probably be simplified a good deal by then too, so I aught to have less material to cover. Hopefully list memebers will be able to say quickly what parts are unclear to them, and we can go through a few revisions of the help doc. > If so I think the next move should be yours. > You might want to do this BEFORE you (or I) do any more coding. I will > still take a quick look at your existing code - just haven't gotten to it > due to a flood of emails. I think you looking at the code might be a good idea, at least until I get a help doc out. Some of your replies below were incorrect because of assumptions. This could probably be avoided if you looked at the code logic. <snip> > >> This is also related to my thought that the first field should not have > >> to contain a * even if the 2nd field (then used only for matching) does. > > > > The first field doesn't have to contain an asterisk currently. I thought > > it would be a good idea to make the code as 'dummy proof' as possible, > > and I could > > imagine the users yelling at me that their logindomainlist file didn't > > work because they forgot the asterisk. > > But wait a minute. In my mind there is a big difference in what it means > whether it has an asterisk or not. If the first field does not contain an asterisk, it looks like this: bob.com:bob.*:* or this: bob.com:mail.bob.com:* There is no magic their. I don't attempt to 'guess' where the asterisk should go. It simply doesn't exist. The second example above details why I'm thinking about removing the '@' modifier. That example is exactly the same as an '@' modifier statement, and it only incurs a tiny bit of extra processing time in the loop. > It is not just a matter of allowing it > to work with the asterisk missing - at least that makes me think you were > going to attempt to GUESS where the user MEANT to put the asterisk. Maybe > you didn't mean that, but if so I think it's not a good thing, because the > field ALREADY has a meaning without the asterisk. The asterisk in the > first field IF PRESENT just means that text is substituted there, based on > what matched the * in the second field. If the asterisk is NOT present in > the first field it means the first field is taken literally, with no > substitution. The purpose of the field is to determine literally the > default login domain (with empty meaning no default). > > But the bottom line here is that the * notation is expressive and already > somewhat standardized. Make no deviations at all from that and you create > less confusion - look for other ways to add flexibility, but don't make the > asterisk IMPLIED. Things as they stand are becoming totally "tight" (in > the good sense) and I don't want to throw that away for the sake of a tiny > bit more brevity. People can learn how to type * if they mean *, and learn > that it means something different if no * is there. The strictness of this > will make it EASIER to learn, not harder, on the whole. I think all of the above commentary was based on an incorrect assumption. > > > In addition, the second field doesn't have to contain an asterisk either! > > This was implemented for the same reason as the first field. > > Hmm... The only way I can think of the 2nd field not needing an asterisk > but doing something like wildcarding would be if you are saying something > like the match can occur anywhere in the string, like saying that xyz > (without any asterisk) might mean the same thing as *xyz* (yes, two > asterisks - which I think we want to stay away from anyway) or maybe you > meant *xyz or xyz*, but either way I think this is an unnecessary shortcut > that causes problems. See the second example in the commentary above. It makes perfect sense, and it avoids user error by allowing non-wildcarding without having to change the modifier to a '@'. It's intuitive. > > I think the * in the 3rd field to mean "wildcard" should be only an > optimization (if necessary) that allows you to avoid checking whether a * > is present in the 2nd field - probably a minor point in terms of > performance, but also safeguards against the possible need for an * in a > domain name, just in case someone ever needs that. Yeah. I'll keep the '*' in the third field. I'm not about to start guessing. > > But: if we could prove that an * can never occur in a domain name then I > think it would be good to get rid of the * option (modifier) and just let > the 1st and 2nd fields be free-form, This would make the parsing logic unnecessarily complicated, I think. The asterisk in the third field is not unreasonable. > just like all arguments in the shell > are free-form. If there is no * in the 2nd field then no wildcarding is > done. I really like this better and I think it conforms to the > expectations people will already have. Otherwise people will put in an > asterisk and bew wondering why it doesn't work, forgetting the modifier is > necessary. I think this is unfriendly because of the existing unix > precedent. There is no option in the shell to say the * should be > interpreted (although I guess there is in perl). It is always interpreted > if it is present. (The shell provides an escape to prevent interpreting > it, but I suspect we don't need that.) > > What the shell does is pretty well-known and I think that sets the best > precedent to follow. Of course this is only for the 2nd field. The shell > doesn't have something like the first field. But other programs do - but I > think they all use regular expressions. Still I think it is no problem to > use the * in a "substitution" context. > > There is a certain underlying simplicity that guides these suggestions. > I'm not meaning to be arbitrary. So if I'm not clear yet, sure make sure I > clarify further before you dismiss this possibility. So, to summarize: > get rid of the * option in the 3rd field. Instead check for a * in the 2nd > field. This eliminates any possibility that you can _guess_ where an * > might have been meant, but I think this is also a good thing. I'll consider this in future code revisions. The next patch won't include this though, and I won't think about it any further until the next patch is released. We _may_ be reaching the end of the work vs return curve now. We'll see. > > > This raises an interesting question: Do we need the '@' modifier? I know > > you've > > asked that before and I declined to remove it. However, I'm considering > > it now. > > > > The '@' modifier adds a little bit of speed to the parsing process for > > strict '@' domains. However, I don't see speed being as much of an issue > > now with the wildcard rewrite rules in place. As I mentioned above, I can > > successfully rewrite ALL of my domains with just three logindomainlist > > lines per machine. I just can't see this file growing to over 100 lines > > if the user comprehends the wildcard rules. > > Aha - I wrote all the below and then realized you probably meant to say you > were considering deleting the '*' modifier. Another incorrect assumption. No, I simply meant that I would get rid of the '@' modifier because the '*' modifier can handle this functionality already. It's redundant. > But anyway, I'm not going to > delete any of this because of the line of thought that resulted. Back to > what I wrote before I realized... I'm listening... > > > I don't remember suggesting that. Maybe you didn't. Someone did. Doesn't really matter... > I might have wanted a different > character at some point. I suspect again you would have to do some > guessing. I think right now the @ modifier means that the hidden field > will be present, and also the "@domain" text will appear instead of the > popup. When the 1st field is blank, there is no need to say whether the > popup should appear. But if the 1st field is not blank, you have some way > to distinguish wheter the login domain that results from the rest of the > logic should be used for the popup default versus the hidden field. Well, you're thinking that I'm going to be doing guesswork, but I'm not. See the above comments about the '@' vs '*' modifier. > > I think you can get rid of the @ if you provide an option that activates > the popup - this is kind of the reverse, but maybe it is the better way to > go. Maybe this is good. Not sure what drop down menus have to do with this. The '@' only effects hidden fields, as you mentioned above. > I'm half forgetting everything but let me try to > summarize the way things are and the way they could change. > > The way I think things currently stand (even if not fully implemented): > > 1st field empty all features off - user must type domain No. No DEFAULT domain. For hidden fields, no hidden field because their is only one choice - the default. For drop downs, we default to the first option, which is nothing. > 1st field present with @ the default domain is used as hidden field, > and also appears after @ for user's clarity Yes, but this functionality exists in the '*' modifier as well, and I'll be removing the '@' modifier. > 1st field present w/o @ the popup is shown, and the default domain > is used as the initial popup choice Yup. > > Is the term "default domain" really correct, or is it confusing? It's the best way that I've thought of to describe it. I think it's descriptive enough. > Clearly > with the popup it is correct. But without the popup is it a default or is > it just the login domain? It's a HARD default. You can't choose anything else. It's a default from the perspective of the logindomainlist file, but not necessarily the user. I may note this distinction in my docs. > It is a default it the user can still override > it. Otherwise the term default is a little confusing, perhaps, and the doc > should maybe avoid using it except in the case when the popup is used. In > either case the code is still computing a domain, and it might be nice to > have a name for that. In one case it is used to default the popup, in the > other case it is the hidden field (and the text after the @ that appears > instead of the popup). > > But let's put that question aside until you tell me what happens if there > is a default domain, and no popup, and the user types a domain after their > user id. Does the typed domain override? Or is it an error? Don't worry, > we don't have to get too sophisticated about all this. Just good to be > aware of so the doc can be written more clearly. > > Now back to the topic. Here is an alternative to the way things stand. > Here I'm inventing a new option character '&', not because this is a good > choice, but just to use something completely new for the moment to avoid > conflicts with anything we have already talked about. I would rather not > be confusing different meanings for the same character in this moment. So, > the alternative: > > 1st fld empty w/o & dflt domain is empty - user must type it > 1st fld empty with & dflt domain is empty - use the empty popup item > 1st fld present w/o & dflt domain is used as hidden field, > and also appears after @ for user's clarity > 1st fld present with & the popup is shown, and the dflt domain > is used as the initial popup choice This is like inverting the functionality of the '*' or '@' and replacing it with '&'. You're suggesting that we do away with the '*' modifier ( or '@' ) and replace it with an '&' modifier. The '&' modifier then specifies whether or not the drop down will appear. I don't see the point. We already know when the dropdown will appear, and this '&' symbol would seem to get in the way of the grouping functionality. I think we'd be reinventing the wheel to implement that. > > So you see this creates "orthogonality". Whether the 1st field is empty > and whether there is an & are two orthogonal feature, meaning they act > independently, and can be combined without the meaning of either being > altered. 1st field empty means the default domain is empty (and that's a > no brainer anyway). & means the popup is used. If there is a popup the > default domain is used to initialize it, and otherwise the default domain > goes into the hidden field. > > And this also takes care of the other issue I was raising about the need to > distinguish the all features off case from the popup defaulting to empty > case - those just become the 1st and 2nd items in the 4 possibilities > listed above. > > There are other ways - no limit to the possibilities, but I think this is a > pretty good one. If you like it lets just decide on the character to use. > I actually don't like ampersand very much. Personally I would go with P > for popup, but I think you wanted to go with spelled-out options rather > than letters - though I don't see why if you were going to use > single-character symbols anyway - might as well use single character letter > abbreviations if they are just as pnemonic. > > I think it is worth writing a little spec here for how the default domain > (or whatever we end up calling it) is computed. If we both agree to this, > then that eliminates another potential source of ambiguity or confusion in > our discussions. I am writing this AS IF you have agreed to get rid of the > * MODIFIER, and just use the 2nd field to determine whether wildcarding is > being done. I think the '*' modifier is staying, at least for the next patch. > > Here is the "spec". I am ignoring the IP domains for the moment so this > doesn't get too complex. As you said the IP domains are simpler, and don't > need so much explanation. I don't mean that the documentation should read > like this. I just want to make sure our communication is 100% clear. > > ===== > The default domain is computed as follows. > First the matching record must be determined - it is the first record whose > 2nd field matches the HTTP_HOST environment variable. The optional use of > a single * in the 2nd field is honored in the matching process, and has the > 'usual' meaning. The match against the 2nd field determines the > "substitution value of the asterisk. > If there is an * in the first field, the subsitution value is substituted > for this *, and the resulting string determines the default domain. > If there is no * in the first field, the the value of the first field IS > the default domain. > If there is an * in the first field, but no substitution value, because > there is no * in the 2nd field (not a wildcard match), then nothing is > substituted, and the * is assumed to be literal. (This last point is > tentative, but not very important in any case.) > ===== > If, after reading all of my above comments, you still feel that there is an obvious advantage to the above inversion of the modifier meanings, then we'll revisit it at that time. You know me: One thing at a time. And currently I'm rewriting the string tokenization routines. I hope to release a new patch today. We'll see. <snip> > >> Thanks, > >> > >> Kurt Bigler -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net We are actively looking for companies that do a lot of long distance faxing and want to cut their long distance bill by up to 50%. Contact [EMAIL PROTECTED] for more info.
