----- Original Message ----- From: "Kurt Bigler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 04, 2003 1:36 AM Subject: Re: [sqwebmail] Re: NEW: logindomainlist patch (2nd revision)
<snip> > on 3/3/03 6:42 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > > >>>> 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. > > That in itself, sounds even better, and was one of the things I was > suggested below anyway, as I guess you have seen. Maybe I only suggested it > in the context of the '&' modifier, but it is the same idea. It's implemented in the newest patch. No more '-' modifier. > > >>>> 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. > > Not clear yet. Here's a guess: are you saying that if there is only once > choice in the popup domain list No. The '*' and '@' modifiers have absolutely nothing to do with popups. Popups are only generated in the absence of these modifiers. > that is the same as showing the @domain text > field? If so, there is the subtle difference that the popup allows you to > switch to the blank domain - no default, which I THINK (maybe) allows the > user to type another domain (not listed) explicitly? Or this might be yet > another separate topic for discussion. > > >>> 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 have to say I'm probably not getting what you mean because I have not been > using this as you have. Agreed. I think I need to release documentation before doing anything else. I don't really plan to change anything major in the future, so I think the time is ripe. > Something unspoken is happening here. I have > basically no clue what you might think is made obvious by the second example > above. I get the feeling that you're no longer trying to understand, but rather trying to convince me to modify the patch to your specs. This is a bit unreasonable, and totally unnecessary. I'll release some documentation, and you can read through it with everyone else. That should solve the problem. > > I have one possible clue, but it is just a guess. And I think its confusing > as anything, if I'm right. I thought * modifier specifially meant > wildcarding. And I said ok to having that modifier (which I thought was > unnecessary) but then I think it should be purely an optimization that the > user lives with because it is "reasonable" as you say. But if you start > using the "wildcard" modifier and it doesnt mean wildcard at all, then to me > that is confusing. In that case I have to ask what does this modifier > really mean then? I have the funny feeling that you are getting used to > _using_ these features so that it is becoming "experiential" so to speak - > this is dangerous if things that don't have obvious meanings (to the less > experienced) start to become "intuitive". It happens to all of us when we > get used to something. Maybe this is not what is going on, but here the > test: what does the * modifier mean then? It doesn't really mean > wildcarding. Does it mean something in relation to the popup being there or > not? You have to spell this out because I am not able to guess it. > > If the * modifier meant "enable wildcards" and you don't end up seeing any > wildcard characters, I would say that it is reasonable to forgive that > without giving an error message, because that is easy to do, although > allowing it might allow the user to remain confused. > > So, just to illustrate the absurity that has arrisen by how differently the > two of us have apparently been thinking... from the way I was _previously_ > thinking (and based on all you told me), * was an optimization that allowed > you not to have to look at the 2nd field to see if there was a * there, > because for some reason it is harder to look for the * in the 2nd field than > to look for a * in the 3rd field, so you look in the 3rd field to see > whether you should bother to look in the 2nd field for a *. > > But all the while maybe you had other features in mind for the * operator - > not just wildcarding, and you realize that the way I was thinking about it > seemed to contradict something you were trying to accomplish. But > continuing with how I _was_ thinking... > > If * modifier means wildcarding but there are no wildcards present, then you > can forgive that and give no error, but then the meaninng should be the same > for these two: > > bob.com:mail.bob.com:* > > bob.com:mail.bob.com No. The first example above generates a hidden field. The second _WOULD_ generate a popup, but unfortunately there is a small bug in the current patch that requires the second example to look like this: bob.com:mail.bob.com: Omitting the last ':' will cause an error. This bug was introduced by the new string parsing function, mystrsep(). It makes parsing easier, but it's a little less forgiving. > > So before you jump, just back off a minute and see if you can appreciate how > much you confused me with this - and try to get what I must have been > thinking all this while. Its kind of funny actually. Will be interesting > to see how this resolves. Again, I don't think it's something that a good dose of documentation can't cure. I've made changes very quickly to this patch. It's understandable that you'd be confused a bit. > > However, I think it would be an unfortunate thing if the "wildcard" modifier > combined with no wildcards present was given another special meaning. This > is not intuitive, unless in fact the * modifier has some other _tangible_ > meaning other than "enable wildcards". Otherwise there is a name for this: > "non-orthogonality", something which is generally considered good to avoid, > excusable (and common enough) if it only means that certain feature > combinations have not been implemented internally, but something that should > not leak into the design of an interface unless it is really necessary. > > Remember I am all too willing to give up any "enable wildcards" modifier. > Maybe you have already given it up and just not told me the new meaning of > *? Well, I've changed my mind yet again with regards to removing the '@' modifier. I don't think I will remove it now. The reason for this is that the '@' modifier is capable of operating on IP addresses as well as HTTP_HOST. For example: domain.com:13.13.13.13:@ The '*' modifier cannot operate on IPs. It operates only on HTTP_HOST. Because of this, I think my vpopmail hook would be best implemented inside the '@' modifier, rather than the '*' modifier. > > >> 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. > > No guessing is involved from my standpoint - really. But I think you have > some features going on here that I don't yet know anything about, and > haven't even dreamed of. Not really. I'm just thinking in a 'modifier centric' way in order to facilitate easy implementation of future functionality, while I think you're thinking in a 'minimalistic' way. You'd like to see things as simple as possible. I understand that, but I'm not willing to give up extensibility for ease of use. Besides, I don't really think it's going to kill anyone to read what each modifier can do. Most people will only need to use the '*' modifier. > > I don't really want to look at the code yet in order to learn what you mean, > because then it is too confusing whether I disagree with how you implemented > something, found something wrong, or just disagreed with what you _meant_ to > do. > > I will probably look at it anyway, since I have it here, but I won't try to > draw any final conclusions from it. > > >> 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 check for * in 2nd field instead of 3rd. Parse the whole record in > advance, then all these are just as easy. I don't want to implement wildcarding globally because it just doesn't make sense in certain situations. For instance, the drop downs shouldn't ever be generated with wildcards. > > > 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. > > Very unusual for me to miss seeing redundancy - that seems to be my job a > lot of the time! Better wait on this until the * issue is clarified. It's redundant in that both this: domain.com:domain2.com:* is the same as this: domain.com:domain2.com:@ But, the '@' modifier can also do this: domain.com:13.13.13.13:@ And because it can, I think it should stay. > > >> 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. > > Good to know. I think that's fine. A short note in the doc will do it. > > [big snip here - my whole example with '&'] > > > This is like inverting the functionality of the '*' or '@' and replacing it > > with '&'. > > Yes, and I think maybe there was one logical combination that became clearer > or more meaningful to me as a result, but I will wait to comment further > until the other issues are resolved. > > > 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. > > Yea, there's another good idea. Particularly if there is any confusion, > much better to bounce back and forth only one topic at a time. > > I'll just say one thing. To me wildcards have always meant nothing else > besides wildcarding, just like in the shell. Not sure where you're going with this. A '*' in the third field is not a wildcard. It's a modifier. An '*' in the first or second field will ALWAYS be treated as a wildcard as long as you're using the wildcard modifier. There's nothing confusing about that. > The cp command doesn't do > anything inherently different because of wildcards. In fact it doesn't even > know there are wildcards. We have a different situation because the > wildcards are used to determine only a single matching record - not a bunch > of items to be operated on. So it is even simpler than the shell, in a way, > but the idea still applies, so maybe this was worth saying to clarify how we > might have been thinking differently: a wildcard is just a wildcard - all > other effects of the line are completely unchanged except that the 2nd field > can match multiple domains on a single line, and the 1st field then gets a > substitution feature at the same time. > > -Kurt > > >
