Ketarin 1.0.1 (beta)

[appyface]

Perhaps you feel it is just semantics :-) but I disagree, the current log wording will still be inaccurate if you clear the previous value when the variable is changed.

 

Replacing {vers} in '{vers}' with '2.16.830'

Update required, {vers} has changed from '20090208test' to '2.16.830'

 

Even if it were to state:

Update required, {vers} has changed from ' ' to '2.16.830'

 

that will still not be correct, as {vers} has *not* changed from last run to this run. Only the value stored for the CIV does not match the current value derived for it...

 

That's what I was getting at. Do you see what I mean?

[floele]

As I said, "clear" is not string.empty, but nothing (null). Thus Ketarin will not mention it in the log at all and will not care about the variable.

[appyface]

If I am understanding you correctly, then Ketarin will completely ignore the presence of the Change Indicator Variable on the first update check with it, or ignore it on the first update check that is using a different variable name?

 

OK let's take that through the same example I've been using:

 

1. My CIV was referencing {testvar}, the last value saved for CIV was 20090208test.

 

2. I change the CIV to use {vers} instead and issue CTRL-U.

 

3. Ketarin doesn't download. This looks OK to me (but not for the right reason -- I know that {vers} contained '2.16.830' the last time, and it has not changed this time.)

 

4. Ketarin saves '2.16.830' for the CIV before concluding.

 

5. I repeat the CTRL-U. Unless by some twist of fate {vers} just got a new value, Ketarin still won't download because the saved value and the current value of the CIV are a match. OK that still seems right. If and when {vers} gets a new value, Ketarin will download.

 

 

Now, let's try altering the example slightly:

 

1. My CIV was referencing {testvar}, the last value saved for CIV was 20090208test.

 

2. I change the CIV to use {vers} instead and issue CTRL-U.

 

3. Ketarin doesn't download. This time {vers} got a new value of '2.16.900' though, which is different from last time.

 

4. Ketarin saves '2.16.900' for the CIV before concluding.

 

5. I repeat the CTRL-U. Unless by some twist of fate {vers} just got a new value again, Ketarin still doesn't download because now the saved value and the current value of the CIV are a match.

 

In this case it looks like I will never get this new file (unless I stop using a CIV altogether)? Or do I still not understand what you're proposing when variable used for the CIV is changed?

Edited February 8, 2009 by appyface

[floele]

> 3. Ketarin doesn't download.

 

No, it depends. As I said, Ketarin completely ignores this additional feature and behaves the same way it would if the feature didn't exist.

[appyface]

OK -- since the premise of the CIV is to control whether Ketarin downloads (or not), I didn't catch that wrinkle. "Let's" document this soon :-) as I don't think it will be immediately apparent just why the CIV is being ignored. Maybe still write a log entry that the CIV is being ignored one-time only due to first time use of CIV or because the variable name was changed?

 

Thanks for clarifying,

--appyface