on 3/2/03 7:13 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> Oiy! This is a long one! I'm starting to wish that I had payed attention
> in typing class. :) It's all good content though. See comments below:
Yes, it was long, and now it is even longer - however, I have learned my
lesson - for better or worse I am putting down all my thoughts, and not
being abstract (unless I slipped). My hope is this means our remaining
communication will be be free from mis-guessing each others meanings. So
yes, it is long, but experience in these 2 weeks has proven this will save
time anyway...
So here goes... (unfortunately didn't proofread every last bit carefully)
>
>
> ----- 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>
>
>> I certainly don't mind if you do the work! I have no real need for glory
>> (referring to your point below), and don't expect much glory from putting
>> icing on the cake of what you did.
>
> Well, I would imagine that it depends on the work being done. If we're just
> talking about logic here, then I might as well do it since I screwed it up
> in the first place.
>
> If we're talking about a genuinely _NEW_ feature (and not just a fix to my
> screwy logic code), then I'll let you implement it. (Unless I really need it,
> but I'm actually pretty happy with the code as is.
Ok.
> I can currently implement
> logindomainlist rewrite rules for ALL of my domains on two different
> machines with just three lines in each file. That ain't bad.)
Yes, and for me it is just one line!
>>> But, I really wouldn't mind having you look the code over. You haven't
>>> stated
>>> your aptitude or experience level in C yet, but if you're capable it never
>>> hurts
>>> to proof read.
>>
>> I guess I have been programming in mostly C and C++ for 20 years.
>
> Alright, well, I already had a good bit of respect for you because of your
> critiques, but now I realize that it's well founded. Thanks for taking the
> time to critique me and my code. This logindomainlist functionality wouldn't
> be half as useful without your input.
And likewise.
>> The last
>> 10 years have been mostly C++ years, but recently stepping back into C for
>> unix server work was not at all alien. In the SqWebMail code I didn't see
>> any ways that C++ would have benefited it, and I was completely comfortable
>> working in the C.
>>
>> I would say that I usually find things wrong with almost any code I look at
>> - almost instantly - a bug at a glance every 30 lines or so.
>
> I don't find bugs so easily, but I do generally dislike other people's coding
> styles. I personally find myself wishing that the sqwebmail code was more
> heavily commented at times, but people who read my patch may find themselves
> wishing that I didn't comment so much!
>
> I'm still trying to find a happy medium, I guess.
Comments are a problem. Sometimes I write them and don't understand them
anyway. So often enough I write 20 or 30 line comments, knowing that a year
later I won't remember the process I went through. But that is one
guideline that has helped me the most. Code is often thought of too
statically. But it is created as a process of successive changes. The
programmer experiences the code as a process. So I find that the best
comments are those that comment about the process, giving enough context
that the steps can be retraced.
On the other hand, if I am unclear about what I am doing, I think it is best
to write no comment at all - except of course to say "not sure what I'm
doing here yet". Such a comment is incredibly helpful if 2 years later
there is a bug right there and I don't have to wonder whether there was some
good reason that I can't see why the code is the way it is - there isn't!
Rip it out!
Dealing with other people's styles and aesthetics is always a challenge but
necessary. Code like other's coded before you in a file, and the result
will be less of a mess, even if you don't like the style. Unless you think
you want to and have the right to change it all - which is sometimes
important if you are really about to become the new "owner" of the code.
[snip]
> OK. Understandable. I still think I'll probably code the below fixes myself.
> After all, I messed them up in the first place.
Great, as usual!
[snip]
>> The way I _think_ it could/should work is that the first matching line in
>> logindomainlist determines everything. No other lines have any effect.
>> Sequence of lines only matters in that it determines which match will be
>> chosen when multiple items might match. The 2nd field determines the match
>> and if it contains wildcards and wildcards are enabled, it also determines
>> the value of any * occurring in the first field. Then the remaining fields
>> determine the result:
>>
>> the 1st field determines the default domain for login
>> and may be empty to specify that no default should be used
>> (this is not a new idea is it?)
>
> Not a new idea. But also not properly implemented in the current patch. I'll
> have to fix this and release a new patch.
>> the 3rd field determines how the default domain will be used,
>> @ = just sets the login domain, and shows it, no popup list
>> otherwise = sets the default for the popup list
>
> Sure, you could use the '=' character, but currently it's just: 'anything
> besides the '*', '@', and '-' characters creates a drop down and defaults it
> to the defaultdomain.
No I didn't mean to imply anything about the '=' character - I just
neglected to line up the two '=' so you didn't see the pattern - just look
again.
>> 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. The second field is still used to match against,
no? Without the second field the entire record would be meaningless - you
have to pick which record is the match before any fields in that record have
any meaning. You look at the 2nd field in the matching process. Only after
you have a match do you look at the 3rd field. Isn't that right?
>> Correct me if I'm wrong but I think it is not used for anything - you did
>
> I use the '-' modifier currently, but only because the blank first field
> doesn't work yet. :)
>
>
>> say no hidden fields, no drop-down, and as I see it there is no other use
>> for a login domain, so it does not even make sense to HAVE a value in the
>> first field - there is nothing to put there that means anything at all.
>
> Yeah the current code just ignores everything if there is a '-' in the
> modifier field.
>
>
>> So
>> it might as well be empty, and the fact that it is empty might as well be
>> the flag that there is no default domain.
>
> Yup. You're right. In hindsight I think this is much more logical too. Like
> you said before, I'm a one-change-at-a-time kind of guy. The '-' option put
> this functionality into the code and made it useable. Now I can clean it up
> and make useable become logical.
Great! Small steps are a great way to learn. In fact I always do the same
thing. Its just that I usually don't do it in public. Willingness to
expose one's steps in public is actually a great thing, I don't know if you
realize. We either think together or we think separately. Thinking
separately may work for somethings but always has its limitations, so it is
a bad habit to develop, and should be used consciously. Its taking me some
time to get over it. When I write less clearly it is because I am leaving
half my thoughts out!
>> 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. 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? 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.
>> Your original comment was "If you're using wildcarding, then it wouldn't be
>> supported." referring to the empty first field which normally (or so I
>> thought) means that the popup and the hidden field should both be
>> suppressed. And I thought there was no need for the wildcarding case to be
>> any different from the non-wildcard case: empty 1st field means turn off
>> the features. As I recall, this "original" functionality can result in 4
>> ways:
>> (1) no logindomainlist file
>> (2) no match found in the logindomainlist file
>
> Yeah. That's right.
>
>
>> (3) matching entry has first field empty
>
> Not implemented yet.
>
>
>> (4) matching entry enables popup list, and the blank entry is chosen
>
> Not implemented yet.
>
>
>>
>> (Possible notes there for the documentation.)
>
> I agree.
>
>
>>
>> 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. 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.
> 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.
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.
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, 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.
> 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. 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 don't remember suggesting that. 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.
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. 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
1st field present with @ the default domain is used as hidden field,
and also appears after @ for user's clarity
1st field present w/o @ the popup is shown, and the default domain
is used as the initial popup choice
Is the term "default domain" really correct, or is it confusing? Clearly
with the popup it is correct. But without the popup is it a default or is
it just the login domain? 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
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.
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.)
=====
>> I
>> know this isn't regular expressions, but the concept is analogous anyway:
>> regular expression substitution does not REQUIRE that a wildcard field int
>> he match string be referred to in the substitution string.
>>
>> This leads into the next item...
>>
>>>> (3) it probably allows one more feature, important or not, that I don't
>>>> think was brought up, which is to map several web domains via wildcard onto
>>>> a single mail domain - perhaps useful if you have a .com/.org/.net combo
>>>> but don't have aliased mail domains
>>>
>>> You can map .com/.org.net combos already. Say the domain is bob.com. If you
>>> put:
>>>
>>> bob.*:bob.*:*
>>
>> No I was really talking about:
>>
>> bob.com:bob.*:*
>
> This works currently. Try it yourself. This is functionality that I may use in
> the future, and contemplating it is one of the things that led me to implement
> non wildcard functionality for both the first and second fields under the '*'
> modifier.
>
> I didn't mention it in the release email because I though that only the people
> who followed our conversations closely would assume it wouldn't work. Everyone
> else will probably think it's only natural.
Great!
> <snip>
>
>> I've installed your latest now, but haven't looked at the code yet. Do you
>> think it is supposed to meet the wildcarding criterion as I described it
>> originally? The main point would be not to require the * in the first
>> field, and to let the * appear in any context in the 2nd field. It looks
>> now like the 2nd requirement is probably met, which I am guessing is what
>> let you get rid of the allvirtual option.
>
> I think the allvirtual thing was just common sense once I started coding.
>
> "Keep It Simple, Stupid", you know?
>
>
> <snip>
>
>> I'll look at the code soon, maybe tonight. I'll get back to you directly,
>> off-list, with any feedback on the code, since I figure this is not really a
>> coding forum. I don't expect any "coding" feedback per-se. More likely, I
>> might have feedback on the logic.
>
> I agree. I think this is more of a user support list. However, since there is
> no '-workers' list to speak of, I don't think it's that big of a deal.
>
> And the users have definately helped me out with the logic side of things.
>
>
>>
>> But it sounds almost as if most of my concerns might have vanished and I
>> have nothing to do. I still want to get clear about the '-' option.
>
> Yes. One final comment here. The '-' option is probably going to be
> technically
> complicated to remove. The reason for this is that the strtok() function isn't
> as well implemented as it should be (on FreeBSD anyway).
>
> If we have a string like this in logindomainlist:
>
> :domain.com:*
>
> The strtok() function will return 'domain.com' as field one. Where logically
> field one should be empty. I'll either have to wrap the strtok() function, or
> implement a sqwebmail_strtok() function with modified strtok() code copied
> from
> my system's source code.
Let's use something that works. Wrap it or write it. (Notice how I say
"let's" even if you get to do the work! Don't trust people who do that!)
> I'll see which is easiest, but I'm not all that opposed to just including an
> sqwebmail specific version of strtok(). I've always been a little worried
> about
> it's portability. I don't know how many systems conform to the ISO/IEC
> 9899:1990
> standard, or even what is covered in that standard.
>
> Thanks for reading, Kurt! I appreciate the input. Together we're making this
> patch a real solid piece of work. I'm sure sqwebmail users will appreciate our
> the functionality for years to come.
Absolutely. I learned some valuable things in the process.
Well, I still haven't gotten to looking at the code. I have absolutely no
resistance to that but the time hasn't materialized! Anyway that is next,
but I think I might be running out of time for today.
>
> Jesse
>
>>
>> Thanks,
>>
>> Kurt Bigler
>>
>>
>>
>
>
