on 2/26/03 3:40 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote (apparently
off-list):

> On Wednesday 26 February 2003 18:22, Kurt Bigler wrote:

[snip]

>> I forgot to mention one other thing I was confused about.
>> 
>> I want to make sure that the original * and @ functionality were both being
>> represented in this new offering.  Somehow that wasn't clear to me.  It
>> sounded like @ would do what * did, and * you were calling the wildcard
>> modifier.  Are you saying the wildcard modifier would enable the
>> interpretation of wildcards?  If so they why is this needed rather than
>> simply the presence of the wildcards themselves?  We aren't worried about
>> domain names containing *s are we?  (Sorry if I read things too fast.)
> 
> It makes the code easier to write. I can't see why anyone would prefer the old
> '*' modifier over the new '@' modifier, so the new '@' modifier is taking it's
> place.
> 
> The '*' modifier will become the wildcard modifier, telling my code to
> implement
> the wildcard algorithms. Sure, I could infer this from any field that has a
> wildcard domain, but this would lead to syntax issues and make my code harder
> to
> comprehend and generally slower.
> 
> Is there a problem with that?

Ok, I just figured out the problem here.  (But don't worry, because the
problem goes too deep to be corrected.)  I was about to say that you still
might want wildcard mapping when you are using the domain list popup, which
requiring the * flag would preclude.  But then I saw the obvious conflict!
This takes me back to your originally separate domainmap file. Because I
"knew" you wouldn't want wildcards (how wrong I was) I did not bother
mentioning that that was the one reason that would justify keeping the
domainmap file separate:  because then it could use wildcards while an
explicit list of domains would remain in logindomainlist.

Not sure that I have any real regrets though.  But thought I'd mention it
for completeness.

Really the problem is that thoughts fly much too quickly and most of them
can't be captured in time in an email.

-Kurt

> 
> 
>> 
>>> -Kurt Bigler


Reply via email to