> Walter,

> First, I want you to know that I HIGHLY respect
> your intelligence and logic.
> {{{text elided}}} and I hope you understand
> that I do likewise.

definitely agreed (and in reverse)...

> Usually I feel that you understand quite well what
> I am suggesting. On the other hand, I'm sorry, but
> I often have trouble understanding your
> suggestions. Often it is because they are very
> long, and, to me, very hard to follow. Sometimes I
> just don't have the time it would take to
> thoroughly dissect them and get to the core of
> what you mean. Please don't take offense at that,
> it's just that my mind doesn't work quite the
> same, or as quickly, as yours.

We have to work on this part somehow... Long they are, but usually because I am trying to be precise and indicated the "why"... Not working the same is no surprise (I'm surprised when someone's mind DOES work the same), but we need to find a way that I can say things in a way that you (and others) understand...

A part of it is that I am basically a mathemeticion and programmer/architect, so I believe strongly that the details DO matter...

> Because the case which is at issue here is
> EXTREMELY important, I have taken a lot of time to
> try to understand what you are suggesting. Monday
> night, before leaving the office, I printed out
> your posting and took it home. There I sat down
> quietly and pored over it, making notes and
> thinking about it. With all that, I am STILL
> having difficulty understanding it! I might be the
> only one here that is having this difficulty.
> However, although I can't speak for others, I
> doubt it.

> First, there is a BIG semantics problem. Just a
> couple of examples:

> 1. In your previous posting you said:

> Obviously by your response to mine, I did not,
> (and still don't), have a CLUE what you meant by
> "overloaded". I thought you meant
> something like "included", and since
> Identical already includes a test on both the size
> and date, (which I simply want to break out into
> separate choices), I responded accordingly.

> 2. To my summary suggestion, which was, to me, the
> most important part of my posting, you made ONLY
> ONE comment, in the middle of it:

> They ARE NOT TOGGLES...!!!

> Throughout this and your "Alternate"
> posting you continually use the word
> "toggle". So what's this all about?
> "Toggle" is simply a convenient word,
> used here to refer to these input options which
> have alternate settings, like (yes, no), etc.
> Someone some time ago in a posting used this term,
> and, it seems, we have all picked up the practice.
> Maybe you mean that a "toggle" should
> have only two states, (which is NOT the case), but
> I'm really not sure WHAT you mean, and am at a
> loss to understand why you found that pointing
> this out WAS SO IMPORTANT...!!!

Hmmmm... I think there is a "symantics mapping" problem here, since the words one uses often affects how one thinks about something -- In fact, I think it may well be that you are thinking of Identical/Unique/etc. (the middle line items) as "toggles" that is at the base of where we are not communicating... The word "toggle" has an overtone of setting a choice or option (a [front-end] "control" parameter), and I don't think of the middle line items quite that way any more...

> Also, when you get into describing the ORDER that
> the tests should be made, I have difficulty
> understanding it. It seems that we simply set the
> "toggles", (forgive me), and hit Enter.
> Why should we care what the order is? Everything
> is in a particular STATE, so the order should not
> matter. I'm satisfied leaving it up to Kim to do
> the testing in the order he sees fit. If the order
> matters because of "AND/OR" logic, then
> we have a problem, because I don't think most
> users will be able to understand or memorize the
> correct order.

The description of the "order" is real since it does matter (to Kim and in a few edge cases) what order the checks and tests are done, e.g., if there is no "matching" file, one can't check anything else... In addition, some things like Case or SFN sort of take priority over things like date... It also matters for getting the best performance, but YES, for the most part the various checks are just an "AND" and most users will not care -- however, we are doing design here as well, so I think that the edge cases DO MATTER.

I do agree that that text was one of my less clear efforts... Once we get together on what I am proposing (understanding, not necessarily agreement...), then go back and read it again, it will probably make sense -- In fact, it was during that test that I "broke loose" of thinking of the middle line items as "toggles"...

I think it does matter what the details are, but I think that it does pretty much what one might work out or expect JUST from the wording of the prompts and a little bit of logic.

> Finally, I find your examples of "throwing
> pairs at buckets" a bit difficult to follow.
> Again, this might just be me, but I seem to be the
> only one here trying to respond to you, so I need
> to understand it. (Of course it's Kim who REALLY
> needs to understand it, but as users we ALL do,
> and I'm just trying to help).

AAHHHHAAA!!! That's the trick! I think of what is going on in the Compare/alt-Compare (see below for alt-F4) as a classification process... I'll see if I can make it clearer here -- First, don't even think about what the user has set for Identical/Unique/Newer/Older/Error (or whatever word we use...--I've changed it to be a bit better, see the modified proposal).

Using just the other settings (the ones on the bottom line which are "toggles"), classify as follows:

1) Find the matching target file (if none, "Unique").
2) Check the name restrictions -- if fail, "Error".
3) Check for "Identical" (variations by toggles) -- if so, classify as "Identical"...
4) Classify as Newer/Older/Error according to the selected "date thingy".

The "Identical" checks are name/siZe/Body (change from Binary) and maybe for equal "date thingys". The "name" option ignores size and body, so it's always true because we have them matched up already...

The same "date thingy" is used for the check (if specified) and for the classification into Newer/Older since I doubt there is a case where one would want to check one kind and classify by another. The choices here are a couple of variants of "date", "version", and maybe a couple of combos... In cases where the thingies are equal but the files are not, it gets classified as an "Error" (it really is, isn't it), and cases where the two can't be compared are also errors.

Once the classification is done, the file (PAIR) is one of:

Unique -- No matching target file (LFN ignoring case)
Identical -- Satisfies all checks
Newer -- Fails the content/date checks, source is newer
Older -- The same, but source is older
Error -- All the odd cases:
  Failed SFN or Case
  Files different (content) but dates the same.
  Date thingies not comparable.
  Access errors (e.g., WIN386.SWP or SYSTEM.DAT)
  Some others (e.g., no version info if required)

I could see adding one more classification, but leave it at those 5 for now.

The class now picks an ACTION which may, currently, be TAG or NO-ACTION (yes/no). I would like to extend things here to allow untagging, changes to the target file tags, and, eventually, coverage for the tagging extensions I've proposed... The extension to allow modification of the target tags is why I emphasize "PAIR".

That's basically it, everything else is coverage of details and being (overly?) precise...

> Looking at my three suggestions for the
> Normal-compare individually, I just don't see what
> the problem is.

> 1. Identical (yes, no, date, size) - This seems to
> give you the most trouble, but all I'm suggesting
> is giving us the ability to break out the
> selection of the two compares which are ALREADY
> BEING DONE here. What's wrong with that?

> 2. Binary (no, same, differ) - Here all I'm doing
> is adding "Differ", so we can tag those
> files which are internally different. What's wrong
> with that?

> 3. Binary "AND" logic - Currently Binary
> FORCES the other compares, (except Unique) to be
> IGNORED. All I'm suggesting is enabling
> "AND" logic so we can get combinations
> like "Same contents and different
> dates", etc. What's wrong with that?

> Until I can understand better your reservations
> about this, and your suggestions, I must stand by
> these.

Hopefully I've acheived that this time (if not, I'll try again...). I am covering the same things, just putting it a bit different -- The main difference is thinking of what the user specifies under Identical/Unique/etc. as an action ("what to do") while things like size/binary/etc. control "how to classify". If you separate the two, I think you will see what I am trying to get to...

> Here is what I'd really like you to do to help me:

> 1. Make a list of the options, (in the form of
> "Option (choice1, choice2, choice3)",
> etc.) that you propose to be on the menu. I don't
> care about the order, or what line they are on, or
> whether they will fit, at this point. Therefore
> you do not have to abbreviate them. We'll worry
> about that later.

See the modified alternate proposal... -- Basic choices are:

Classification::
Case: Y/N
SFN: Y/N
content/checK: name/siZe/Body
"conjunction": Also check "date" ("And") or just sort by ("viA")
date: date (not time), version, date&time, some others.

Action:: The same for each class (Identical/Unique/Newer/Older/Error):
nothing
tag [source]
+untag [source]
+++tag target (combines with any source option)
+++untag target (also combo)
+++++eventually, full tagging extensions

> 2. Give us MANY functional examples of how these
> options would be set to accomplish useful
> compares, including the ones I showed, as well as
> compares we would not be able do with my suggested
> changes. I would suggest using the form I did in
> my summary. The settings need only show those
> "toggles" which are set to something
> other than "no" or "none". The
> following is the form:

> Settings:
> Result:
> Note: (optional)

> Do this for both your original method, and your
> alternate method. Then I think I'll better
> understand your proposals, and will be better
> equipped to respond.

Hmm... I will give a few, but I think it is instructive to just pick a set of options and see what it does and how intuitive it is... Most of the possibilities are useful, and there are WAY too many to list out. I also may need to add a small bit to hit a couple of your cases -- they fit in, but I may need to add one setting...

I will post this part later...

> Walter, I am not trying to suggest doing a
> "quick & dirty" here, and I
> certainly do not want to "obviate"
> future enhancements. What I *AM* trying to do is
> keep the menu simple and understandable, while at
> the same time adding power.

Hopefully the modified proposal comes close...

> Regards,
> - John