This time to try to keep it shorter, I'm snipping without mentioning it in
most cases, and anything I snipped out with no response is stuff I agree
about, or no need to comment.
on 3/3/03 6:42 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>>> 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.
>
> No, a blank field means there is no default (in my mind). In the case of
> hidden
> fields, this means that there is no hidden field either, but in the case of
> drop
> downs, it'll just mean that we default to a blank field. I think some system
> account users may possibly find that useful.
That in itself, sounds even better, and was one of the things I was
suggested below anyway, as I guess you have seen. Maybe I only suggested it
in the context of the '&' modifier, but it is the same idea.
>>>> 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.
>
> If the first field does not contain an asterisk, it looks like this:
>
> bob.com:bob.*:*
>
> or this:
>
> bob.com:mail.bob.com:*
>
> There is no magic their. I don't attempt to 'guess' where the asterisk should
> go. It simply doesn't exist.
>
> The second example above details why I'm thinking about removing the '@'
> modifier.
> That example is exactly the same as an '@' modifier statement, and it only
> incurs a tiny bit of extra processing time in the loop.
Not clear yet. Here's a guess: are you saying that if there is only once
choice in the popup domain list that is the same as showing the @domain text
field? If so, there is the subtle difference that the popup allows you to
switch to the blank domain - no default, which I THINK (maybe) allows the
user to type another domain (not listed) explicitly? Or this might be yet
another separate topic for discussion.
>>> 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.
>
> See the second example in the commentary above. It makes perfect sense, and it
> avoids user error by allowing non-wildcarding without having to change the
> modifier to a '@'. It's intuitive.
I have to say I'm probably not getting what you mean because I have not been
using this as you have. Something unspoken is happening here. I have
basically no clue what you might think is made obvious by the second example
above.
I have one possible clue, but it is just a guess. And I think its confusing
as anything, if I'm right. I thought * modifier specifially meant
wildcarding. And I said ok to having that modifier (which I thought was
unnecessary) but then I think it should be purely an optimization that the
user lives with because it is "reasonable" as you say. But if you start
using the "wildcard" modifier and it doesnt mean wildcard at all, then to me
that is confusing. In that case I have to ask what does this modifier
really mean then? I have the funny feeling that you are getting used to
_using_ these features so that it is becoming "experiential" so to speak -
this is dangerous if things that don't have obvious meanings (to the less
experienced) start to become "intuitive". It happens to all of us when we
get used to something. Maybe this is not what is going on, but here the
test: what does the * modifier mean then? It doesn't really mean
wildcarding. Does it mean something in relation to the popup being there or
not? You have to spell this out because I am not able to guess it.
If the * modifier meant "enable wildcards" and you don't end up seeing any
wildcard characters, I would say that it is reasonable to forgive that
without giving an error message, because that is easy to do, although
allowing it might allow the user to remain confused.
So, just to illustrate the absurity that has arrisen by how differently the
two of us have apparently been thinking... from the way I was _previously_
thinking (and based on all you told me), * was an optimization that allowed
you not to have to look at the 2nd field to see if there was a * there,
because for some reason it is harder to look for the * in the 2nd field than
to look for a * in the 3rd field, so you look in the 3rd field to see
whether you should bother to look in the 2nd field for a *.
But all the while maybe you had other features in mind for the * operator -
not just wildcarding, and you realize that the way I was thinking about it
seemed to contradict something you were trying to accomplish. But
continuing with how I _was_ thinking...
If * modifier means wildcarding but there are no wildcards present, then you
can forgive that and give no error, but then the meaninng should be the same
for these two:
bob.com:mail.bob.com:*
bob.com:mail.bob.com
So before you jump, just back off a minute and see if you can appreciate how
much you confused me with this - and try to get what I must have been
thinking all this while. Its kind of funny actually. Will be interesting
to see how this resolves.
However, I think it would be an unfortunate thing if the "wildcard" modifier
combined with no wildcards present was given another special meaning. This
is not intuitive, unless in fact the * modifier has some other _tangible_
meaning other than "enable wildcards". Otherwise there is a name for this:
"non-orthogonality", something which is generally considered good to avoid,
excusable (and common enough) if it only means that certain feature
combinations have not been implemented internally, but something that should
not leak into the design of an interface unless it is really necessary.
Remember I am all too willing to give up any "enable wildcards" modifier.
Maybe you have already given it up and just not told me the new meaning of
*?
>> 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.
>
> Yeah. I'll keep the '*' in the third field. I'm not about to start guessing.
No guessing is involved from my standpoint - really. But I think you have
some features going on here that I don't yet know anything about, and
haven't even dreamed of.
I don't really want to look at the code yet in order to learn what you mean,
because then it is too confusing whether I disagree with how you implemented
something, found something wrong, or just disagreed with what you _meant_ to
do.
I will probably look at it anyway, since I have it here, but I won't try to
draw any final conclusions from it.
>> 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,
>
> This would make the parsing logic unnecessarily complicated, I think. The
> asterisk in the third field is not unreasonable.
Just check for * in 2nd field instead of 3rd. Parse the whole record in
advance, then all these are just as easy.
> Another incorrect assumption. No, I simply meant that I would get rid of the
> '@' modifier because the '*' modifier can handle this functionality already.
>
> It's redundant.
Very unusual for me to miss seeing redundancy - that seems to be my job a
lot of the time! Better wait on this until the * issue is clarified.
>> Clearly
>> with the popup it is correct. But without the popup is it a default or is
>> it just the login domain?
>
> It's a HARD default. You can't choose anything else. It's a default from the
> perspective of the logindomainlist file, but not necessarily the user. I may
> note this distinction in my docs.
Good to know. I think that's fine. A short note in the doc will do it.
[big snip here - my whole example with '&']
> This is like inverting the functionality of the '*' or '@' and replacing it
> with '&'.
Yes, and I think maybe there was one logical combination that became clearer
or more meaningful to me as a result, but I will wait to comment further
until the other issues are resolved.
> If, after reading all of my above comments, you still feel that there is an
> obvious advantage to the above inversion of the modifier meanings, then we'll
> revisit it at that time.
>
> You know me: One thing at a time.
Yea, there's another good idea. Particularly if there is any confusion,
much better to bounce back and forth only one topic at a time.
I'll just say one thing. To me wildcards have always meant nothing else
besides wildcarding, just like in the shell. The cp command doesn't do
anything inherently different because of wildcards. In fact it doesn't even
know there are wildcards. We have a different situation because the
wildcards are used to determine only a single matching record - not a bunch
of items to be operated on. So it is even simpler than the shell, in a way,
but the idea still applies, so maybe this was worth saying to clarify how we
might have been thinking differently: a wildcard is just a wildcard - all
other effects of the line are completely unchanged except that the 2nd field
can match multiple domains on a single line, and the 1st field then gets a
substitution feature at the same time.
-Kurt
