----- Original Message ----- From: "Kurt Bigler" <[EMAIL PROTECTED]> To: "Jesse Guardiani" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, February 27, 2003 1:08 AM Subject: Re: [sqwebmail] new file proposal
> on 2/26/03 7:30 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > > > ----- Original Message ----- > > From: "Kurt Bigler" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, February 26, 2003 7:09 PM > > Subject: Re: [sqwebmail] new file proposal > > > > > >> on 2/26/03 3:40 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > >> > >>> On Wednesday 26 February 2003 18:22, Kurt Bigler wrote: > >> > > > > <snip> > > > > > >> 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 > > > > If you're using wildcarding, then it wouldn't be supported. > > Unless I'm missing something, this could work with wildcarding - you don't > need to add yet another option that doesn't need to be there. It should be > sufficient to check that the first fild is empty and that the wildcard flag > is present. In that case the match is done against the second field and the > login domain result is empty, which should trigger the same effect as the > login domain being empty with no wildcarding. In college, I had a class about mathematical logic. (Conditionals, Loops, etc...) Just because it's logical doesn't mean it's obvious. That was one of the hardest classes I've taken, and I ALREADY knew how to program. It messed with my head. I don't see anything wrong with adding a '-' modifier to signify explicit non- default status. And that is what I've included in my next patch. > > The same argument as I gave in my previous email regarding the *:* situation > applies here for why it is better not to add more "apparent" functionality > when there need be no additional interface presented to the user. > Simplifies the doc. Simplifies the whole gestalt and how the (non-end) user > will be able to receive what is being offered in this feature set. Might as > well make it all look very simple, and then the details are worked out as > needed, with the help of examples. The examples just then illustrate the > power inherent in the underlying simple concepts. > > (Thanks for your forebearance.) > > -Kurt > > > However, I can fix > > that by creating another modifier that explicitly specifies NO default domain. > > > > I'll work that into my code. Good catch. > > > > If you're not using wildcarding, then you can just not include the domain > > you'd > > like to not have a default domain in the list. (This is broken in my second > > patch. I'll fix it in the third.) > > > > > >> > >> 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. > > > > It's easy enough to work in post-patch-release. Very simple fixes. But I'll > > try > > to remember to include this functionality in the third patch, as I can > > definately > > see it's usefulness. > > > >> > >> -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 > >> > >> > >> > > > > > > >
