on 2/26/03 3:40 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> 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.
Just one thing. How is the possibility of entering the domain name in the
user-id field supported now? Is the hidden field just providing a default
for a domain that is otherwise entered in the user-id field? I guess I
never quite knew how that was working.
Typing the domain explicitly certainly still needs to be supported. Is that
covered by the first field being blank, as in the following?
:webmail.whatever.com
I guess this was explicitly discussed in relation to domainmap, but I don't
remember it being described in the enhanced logindomainlist context, and I
just looked back at the doc you wrote with the last patch and didn't see it
mentioned. Also I didn't test that case.
-Kurt
>
> 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?
>
>
>>
>>> -Kurt Bigler
