Just a reminder for those of you using the SOTA support feature in our free logging program Log4om
It is necessary to update the Summitlist.csv at regular intervals by downloading the summitlist.csv from the SOTA database and copying it to your C:…\Roaming\Logom folder.
73 Terry G4POP
Log4OM Development Team
In reply to G4POP:
No it isn’t. It’s only needed when the summits are updated. But you’d know that if you’d bothered to communicate with the people who actually run SOTA. That’s what all the other software authors do, they talk to us so they know what is happening etc.
Andy
MM0FMF
In reply to G4POP:
Thanks Terry
Matt/K0MOS
In reply to MM0FMF:
Andy,
With due respect your list is updated quiet often and we have had users comment about the list being out of date, this is what prompted the post.
I can’t understand why you are always so critical of our efforts when all we are trying to do is support SOTA with a completely free software package?
BTW I tried to contact you a couple of times without any response!
Terry G4POP
Log4om Development Team
In reply to MM0FMF:
It’s only needed when the summits are updated.
The logic seems circular here. You only know for sure that you didn’t need to download the list after you already have.
In reply to M1MAJ:
Sounds like an obvious case for using an “If-Modified-Since” HTTP request, which is the sort of thing an automated “check for updates” function should be doing.
Of course, if they’ve left the downloading of the file to the end user then it’s not so easy.
…and if the file’s re-generated even if the data hasn’t changed, then it probably wouldn’t help, (but I expect there are smarter checks that would).
73, Rick M0LEP
In reply to M0LEP:
…and if the file’s re-generated even if the data hasn’t changed,
then it probably wouldn’t help
The file changes every day, since it includes last activation information.
In reply to M1MAJ:
Then I guess a version with just the essential information (probably no more than name, reference and location) might be useful, especially if its modification date correctly reflected the last time its contents changed.
Certainly, it’s sub-optimal to have users of a program downloading a file “frequently” just because significant parts of it might, occasionally, have changed. However, it would be even more sub-optimal to have the program automatically download the file every time it thought there was a change, especially if only a small proportion of the program’s users are interested in the file’s contents…
I figure, at present, it’d only be necessary to download a new version for the program after association changes have been announced.
73, Rick M0LEP
In reply to G4POP:
Thanks Terry, your efforts are appreciated.
G(M)INK/P
In reply to M0LEP:
I figure, at present, it’d only be necessary to download a new version for the program after association changes have been announced.
Ding! Ding! Ding! Ding! We have a winner!
Currently the summits file is regenerated daily. The summit info changes normally around the 1st of the month when new associations/updates are announced. No announcements then you can be pretty sure nothing changed.
The file also includes last activation info. I don’t know why, but it does since I inherited the app. Changing it would cause issues to people using that data. Occasionally, summit data gets tweaked quietly. Normally in response to someone spotting a typo or such. Martyn M1MAJ has provided many such inputs in the past, some which have been tweaked and there are still more to do. The last error was spotted by Stewart G0LGS.
Much nicer would be to separate out the activation data and I think that will happen when the SOTA mapping project interface is running. The autoregen is done every day around 0417Z (or maybe 0630Z). This is triggered by a cron job requesting an update. If the update fails then I get a mail telling me so. That’s normally an indication somethings is gubbed at the host. So the code would need tweeking so it runs daily but doesn’t touch the actually file the users can see if no summits have changed. You could then do a 304 request.
Andy
MM0FMF