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 only propose this on the basis that there will be no disadvantages, and
>> that you will like the result. And you _don't_ have to do all the work
>> yourself!
>
> Well, if it's easy, it would probably be better for me to do it myself since
> I'm pretty familiar with my own code right now. If we wait a month, I won't
> be, and I'll have to rely on my comments to jar my memory.
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.
> 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. 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. This probably
reflects badly on the code I have had to work with, but I didn't find
anything wrong in the SqWebMail code I looked at, which is kind of a relief.
This includes your code from your previous patch, which I reviewed
completely.
So, I'll take a look as soon as I can, and then we can go on from there.
>
> If you wanna add something while you're in there, then go for it. Submit it
> to the list. If they like it, then it's golden. If they don't, they'll tell
> ya why. :) Kinda like you have with me this last week or so.
I think I'll take the approach of doing the proposed coding (if any is
needed) myself, then passing it to you. You are aware of some things that
I'm not, like ISO/IEC 9899:1990 compliance. Since you have more vested
interest in this particularly piece of code it is probably good if you make
the final pass of clean-up edits before the next patch is posted.
>> Here is what I propose. Let me test your latest, look at your code, and
>> see if I can come up with some minor changes to that code that will
>> accomplish what I am suggesting. Then I'll run those changes by you first.
>> If you find disadvantages, then we just forget it. If it turns out ok,
>> you can leave the next patch release to me if you want, or do it yourself.
>
> Your code, your release. Your glory.
Well, as I said, I'm not really adding much in the way of functionality (if
anything). No glory expected.
>> In the meantime, if you want, we can discuss the actual user-interface
>> (logoindomainlist file) details on the list. I'll just summarize here
>> briefly what I would like to see. I would like the wildcarding
>> implementation to be "complete" by the following criterion, which I will
>> describe in terms of how the doc will look. I would like the documentation
>> to be able to say (not in exactly these words) that you can do anything you
>> want using a single wildcard (*) appearing anywhere in the second field,
>> when used to match against HTTP_HOST, and if a * appears in the first
>> field, it stands for whatever the * matched in the 2nd field. But the * is
>> not required to appear in the 1st field, which can even be blank. I see
>> several advantages:
>>
>> (1) it allows the allvirtual option to go away
>
> Went away already. I'm currently just looking for an asterisk in the modifier
> field. Not sure if I mentioned this in my release notes, but I meant to
> mention
> it in the docs which I haven't yet gotten around to writing.
No I don't think you mentioned it. I'm curious how this came about. Did it
require changes to your wildcard matching or did it just fall out of the
code you already had?
>> (2) it avoids needing to add what you were describing 2 days ago as the '-'
>> modifier
>
> How so? I thought that modifier was pretty darn important.
One of us is missing something here. I'm just going to jump in with my
assumptions and you can correct me as needed. We might have to kick this
back and forth a couple of times to get it clear.
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?)
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
As I see it, the '-' option makes any value in the first field irrelevant.
Correct me if I'm wrong but I think it is not used for anything - you did
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. 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.
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.
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
(3) matching entry has first field empty
(4) matching entry enables popup list, and the blank entry is chosen
(Possible notes there for the documentation.)
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. 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 avoids implementing multi-mail-domain aliasing anywhere else, logging
into any of the matching domains all take you to the bob.com email domain.
The real point is mainly to allow the first field to not have a wildcard -
and I guess I should ask are you sure it doesn't work that way already?
Haven't looked yet. The "feature" here is the ability to map a wildcard set
of websites onto a single login domain - OR: a empty specification to turn
the features off. In either case there is no * in the 1st field.
> Then it'll match anything with bob.*.
[snip]
>> (4) maybe by fully implemeting wildcarding it allows something else we
>> haven't thought of yet
>
> I consider the current setup to BE a full implementation of wildcarding.
> Let me know if I missed something.
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.
>> Though I am being spare on details here, I think I have learned from
>> experiences over the last week that for the participation of the whole list
>> to work well, it is good to have the details spelled out in examples. So
>> if you approve, I will write something up in the next couple of days. I
>> might want to install your latest patch first, so I can see the code and
>> have the implementation in mind. I certainly don't want to go ahead
>> without your approval, since there is no point in fragmenting the community
>> by moving without consensus.
>
> I'm not arrogant enough to contest a patch that the list likes unless it
> breaks functionality I need or might use in the future. If your patch adds
> genuine value to the program then I doubt anyone will complain.
Well it wouldn't necessarily be arrogant to have a way of doing things that
works in a certain community. I'm just stepping in here and don't know the
way things work. I continue to appreciate the openness and how things work
out without getting into any ugliness, even for example when I was not at my
best and ended up being too sharp with my criticisms.
[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.
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.
Thanks,
Kurt Bigler
