Improved Update

[Nologic]

First off I'd like this changed to being more of a global setting than per app...not exactly sure how it came to be per app to begin with...seems like it would be harder to manage.

 

Anyways I'd like to see it broken down into the following triggers with only one of them needing to be hit.

File Not Present

File Size Wrong

File MD5 Wrong (if site listed)

File Version Wrong ether DB or in file Name (if present)

 

Right now I have Version selected in Ketarin...and yet it clearly is checking file size...this is causing a lot of thrashing...if I'm just curious as to how out of date I am.

 

Honestly I think checking the MD5 should only be done rarely...and to a lesser degree file size...as both should be correct & checked upon download...and if failed should be marked as a bad download...and ask the end user if they want to try again or put it off till later.

 

Granted if none of these options are checked...no update could happen...as there are no triggers to hit.

 

For me version and present is what will generally get me by...with occasionally checking file size and rarely checking MD5...provided both were correct when the file first downloaded.

 

I'm sure for folks that just check updates once a month this stuff isn't a sore spot...but I'm trying to automate generation of large application collections...and the thrashing and time involved with checks...it a turn off right now...I just want to see if things are working right now...not make sure everything is anally valid.

 

Anyways it would be a great feature I personally feel to be able to globally set how picky I am about triggering updates.

 

Thanks for your time and the effort thus far put into this application...and I'm sorry for coming off so bitchy.

[shawn]

Sadly, in most cases there's no way for Ketarin to know what the updates are, whether they're an "update" or an older version and what many of the checks you provide would even source to.

 

For example, an MD5 is a great way to ensure the validity of a file. But you have to *get* the MD5 from somewhere so you have something to compare it to. Further, since that value is a mathematical computation based on a file you have access to, you'd typically have to actually download the file to know whether the MD5 is changed. While that's an effective way to validate a file - it's total crap for versioning. That's not to say it's completely useless for Ketarin though. Some applications don't provide an obvious version string anywhere publicly. That means you often can't determine whether the file is an update or not. But if they provide an MD5 on their site you can capture that within a variable in Ketarin and then use THAT VARIABLE (instead of "version" or native behavior) to act as the "change indicator".

 

Ketarin is actually a quite ingenious program, but functionality it's really just a GUI for automating an internal browser. It's designed to use common webserver methods of indicating if a file has been updated (such as ETag), and also parses the headers to obtain the last-modified date. If these values differ from the cached values then an update is performed. Some servers do no include these headers so Ketarin has no way of determining whether the file is newer or not without downloading it. Ketarin offers a way around this situation by use of a "change indicator". This allows you to use whatever values you wish to as the trigger for the update. If the program's website provides a version number somewhere, you can capture that to a variable and use that as your change indicator. That's the most common method. But some programs (such as SUPERAntiSpyware Portable) don't really have a published version number anywhere. It's updated at least daily, but not at the same times, doesn't include an ETag or last-modified header, and the only thing we know for sure is that it's going to be updated daily. In this type of situation you can use todays date within a variable and then use that as the change indicator.

 

While surely this allows it to function fine, most apps don't update daily, and presuming that this behavior is universally appropriate would be a huge waste of bandwidth. I guess what I'm trying to say is that pushing any universal option like this, especially if it depends on unique information on each app profile, is unrealistic. Think of Ketarin like a bakery. What you're suggesting is to organize everything in the entire bakery by whether or not it has frosting. That's fine for the donuts and cakes, but the breads, sodas and many other items are going to be completely mismatched with their new group. It's better to treat each one on it's own merits and attributes, which is why universal behaviors like this are typically frowned upon.

 

It would be nice if there were an option within the "update all" list to provide "update missing". I just don't see any way to reliably declare that those updates should be checked based on their MD5 or some other intrinsic value that might not be universally valid and surely won't be included within the app profile for each app.

 

If I'm misunderstanding the request, please expand upon it.

[Nologic]

Well MD5 would only work if a valid MD5 value can be had of course...FileHippo lists it on the page, Major Geeks have it in the url...but yeah it may not be available in all cases...and in those cases Ketarin should ignore it.

 

in the case of SUPERAntiSpyware it's size could be a trigger...granted you would have to start the download more than likely to get this value...but once gotten you could determine if the connection should be closed or not.

 

I think sorting by frosting is fine if the frosting is present, if not then move to the next possible method to define.

 

I can write this logic up in AutoIt...hell maybe even in C#...have to crack a book open...but ether way shouldnt' be hard...from my point of view anyways. Granted maybe I'm not seeing something...or I'm not being clear enough...which is certainly possible.

[shawn]

The logic is already available: use the "change indicator" variable.