Automatic Script Updating... Discuss!

matt.chugg

Moderator
This is just an idea i'm throwing out there...

IF there was a script repository, either on here or on one of my own servers where script authors could login, and upload the latest version of their scripts, would one of the (awesome) developers be interested in adding automatic script updating functionality to KoLmafia? Obviously we would need to work out a lot of details but I can see a lot of benifit in having a script manager in kolmafia that autochecked (or manual) checked for new versions of scripts and librarys such as Zarqon's zlib, macguffin, smartstasis and batbrain, bale's recovery and ocd managers. I know there is version checking in each one of these, and whilst I am usually on the forums somewhere I'd love to see some way of making the script upgrading process more streamlined!

I'm happy to work on the server side database and php involved in creating this, if someone else is happy to work on the java stuff.

Discuss!
 

fronobulax

Developer
Staff member
In theory it is an interesting idea and I'd be willing to write code to support it.

However...

Script writers seem to be a pretty independent lot. Bale and bumcheekcity have preferred to use KoLmafia preferences rather than zLib preferences. bumcheekcity chooses to host scripts at SourceForge rather than on threads at KoLmafia.us. I'm not going to try and name names but in scripts I am running there are three or four different conventions and techniques used for version checking. Bottom line being that I would want to see several folks commit to a script repository and agree to various conventions before writing code to support it seems worthwhile.
 

lostcalpolydude

Developer
Staff member
As an occasional user of other people's scripts, one thing that holds me back from using them more is that I can't update them without visiting a forum thread (a page somewhere else wouldn't make much difference), manually download the new file, and make sure it ends up in the right place. That's a lot of steps compared to the convenience of having mafia automatically updated while I'm not at home. I don't know if addressing that was part of the vision you had.
 

matt.chugg

Moderator
As an occasional user of other people's scripts, one thing that holds me back from using them more is that I can't update them without visiting a forum thread (a page somewhere else wouldn't make much difference), manually download the new file, and make sure it ends up in the right place. That's a lot of steps compared to the convenience of having mafia automatically updated while I'm not at home. I don't know if addressing that was part of the vision you had.

What you described there is exactly what I am wanting to address with this!
 

StDoodle

Minion
Heh, I think I may be one of those names. ;) Anyway, putting my version-checking more in line with zarqon's has been on my back-burner forever, and I'd be happy with this proposed system as well. The big thing would probably be that users (at least, and authors preferably) have a way to opt-in (not opt-out) of such automatic updates. This also brings back the whole discussion of separate update behavior for "major" vs. "dev" versions and standard versioning schemes.
 

matt.chugg

Moderator
In theory it is an interesting idea and I'd be willing to write code to support it.

However...

Script writers seem to be a pretty independent lot. Bale and bumcheekcity have preferred to use KoLmafia preferences rather than zLib preferences. bumcheekcity chooses to host scripts at SourceForge rather than on threads at KoLmafia.us. I'm not going to try and name names but in scripts I am running there are three or four different conventions and techniques used for version checking. Bottom line being that I would want to see several folks commit to a script repository and agree to various conventions before writing code to support it seems worthwhile.

I absolutly agree, this is why I started the thread before I even thought about coding anything, if enough people like the idea, i'm happy to take on the bulk of the server side code and cover the hosting, i'd like to make it easier for end users to have the most recent version of the scripts, but also for the updating process to be easy for authors to use as well, i'm not sure the full technical details of how it will work yet though.

Personally I find the usage of a thread with specific data in it to determine versions ingenious, but also a little clumsy, and as you say there are various ways of doing things, maybe theres something OCD in me, but something centralised and standard would make me smile.
 

matt.chugg

Moderator
Heh, I think I may be one of those names. ;) Anyway, putting my version-checking more in line with zarqon's has been on my back-burner forever, and I'd be happy with this proposed system as well. The big thing would probably be that users (at least, and authors preferably) have a way to opt-in (not opt-out) of such automatic updates. This also brings back the whole discussion of separate update behavior for "major" vs. "dev" versions and standard versioning schemes.

Agreed, it would be totally opt-in, for large usage scripts/librarys such as zlib, recovery, batman etc, anyone who wants to would be able to put their scripts up though. I'd reccomend their repository account be verified thorugh their kolmafia.us account for trust purposes. As I see it, only major versions would be uploaded, anything that the author would like the end-user to see, dev versions would be upto you to test and distribute to your testers before releasing. (although there would be no reason you couldn't have a development and stable version online and users could choose to keep the dev version upto date instead of the stable. I think)
 
Script writers seem to be a pretty independent lot. Bale and bumcheekcity have preferred to use KoLmafia preferences rather than zLib preferences. bumcheekcity chooses to host scripts at SourceForge rather than on threads at KoLmafia.us. I'm not going to try and name names but in scripts I am running there are three or four different conventions and techniques used for version checking. Bottom line being that I would want to see several folks commit to a script repository and agree to various conventions before writing code to support it seems worthwhile.

If you ask me this is only gives MORE support to matt's idea. Regardless of how each individual author handles their scripts' versions, a central area would be controlled by KoLmafia.
When you add a new version to the site, KoLmafia downloads it and you never have to worry about your scripts flunking out on you again.

Things to consider:
-OS-esque "Updates Available!" dialogue for user confirmation.
-Only download updated versions of the script for which the user is running a suitable revision of KoLmafia [kind of important]

I, personally, think this is a beautiful idea.
 

fronobulax

Developer
Staff member
A concern with opt in, automatic updating is that some people have their very own personal quirks expressed as local edits to someone else's scripts. If opt in means I am going to lose those then maybe I don't opt in. If opt in means the existence of my local changes is detected and I have a way to propagate and preserve then that may be a fair amount of work.

I'm not suggesting we do this, but I am seeing a lot of parallels with a SubVersion repository. Periodically, I fire up the client and tell it to update. It is smart enough to a) only update from the pieces of the repository that I have previously configured it to use and b) detect that I have made local changes and require me to take some explicit action to deal with those. As a user this is pretty trivial. Install the client, configure it and Update as desired. Hmmm...
 

Theraze

Active member
Yeah... most of the newLife changes are awesome, but I want to keep my restoration settings so I don't forget and go beaten-up in a loop when not paying too much attention to automatic adventuring... There's a few other changes like that which would be aggravating to have changed automatically without warning.
 

mad dudy

Member
i like this idea of auto updating with out having to go to the thread.
i see only problem with this idea. someone can hack into someone's account like bale post a fake updated Universal Recovery that sends people meat and items to the hacker.
just throwing this out there.
 

fronobulax

Developer
Staff member
I note SVNKit superficially seems to allow SVN client functionality to be embedded in Java. As an Open Source project, KoLmafia should be able to license it with no issues. It seems to support some basic diff capability and some merging which suggests that local changes could be detected and maybe even propagated.

On the user side, a user is always getting the latest files from the repository so the concept of script versions is effectively superceeded. On the scripter side, it is probably best to consider it as a release only repository and nothing is committed unless it is "final". That would require some administration.

Hmmm... *and strokes his chin*
 

Donavin69

Member
I, as a new script writer, love the idea. I don't know if I follow the best practices, and as a new scripter, I'd be willing to change any of my styles to fit the 'best practices'
 

matt.chugg

Moderator
I note SVNKit superficially seems to allow SVN client functionality to be embedded in Java. As an Open Source project, KoLmafia should be able to license it with no issues. It seems to support some basic diff capability and some merging which suggests that local changes could be detected and maybe even propagated.

On the user side, a user is always getting the latest files from the repository so the concept of script versions is effectively superceeded. On the scripter side, it is probably best to consider it as a release only repository and nothing is committed unless it is "final". That would require some administration.

Hmmm... *and strokes his chin*

This sounds like an option, if the wheel is round enough, and suitable theres no point re-inventing it. what would you need in order to see if this option is viable?

we already have functionality to turn an svn log into xml using the rss feed code I have, so that may be useful..
 

matt.chugg

Moderator
Yeah... most of the newLife changes are awesome, but I want to keep my restoration settings so I don't forget and go beaten-up in a loop when not paying too much attention to automatic adventuring... There's a few other changes like that which would be aggravating to have changed automatically without warning.

I've also modified newlife, and local modifications are certainly something to consider, it should be pretty easy using a checksum of file contents to know if a local file has been modified. In the specific case of new life, perhaps Bale should consider using a datafile, or preferences to store information so that scripts can be updated but still customizable (I think thats exactly why Zarqon wrote the zlib settings functionality)
 

matt.chugg

Moderator
i like this idea of auto updating with out having to go to the thread.
i see only problem with this idea. someone can hack into someone's account like bale post a fake updated Universal Recovery that sends people meat and items to the hacker.
just throwing this out there.

Thats a risk you take everytime you run any script in kolmafia, if accounts were verified through kolmafia.us it would prevent people posing, but to be honest a kolmafia.us account is just as vunerable as any other account to brute force, and social engineering. You should always check a script from any author you don't know before you run it anyway.

Although on an interesting note... the repository could look at mafia scripts for various functions and add notes to the info box "This script may attempt to send meat" , also it could look at the imports and determine dependancies and maybe even bundle the script with them in a zip file as another option.
 

bumcheekcity

Active member
That's why we keep our setting separate from our scripts, using zLib variables (for most of us) or crap in the /data/ directory (for me and some others).

I'm really, really in favour of this. I'd suggest as people already have:

  • That the /dev/ version(s) of our scripts are kept however is best for the scriptwriters.
  • The new versions could be uploaded to kolmafia.us/scripts/bumcheekascend.ash, and the old version then renamed to bumcheekascend-0.36.ash to allow for using old versions if necessary.
  • An md5() check on the script on the users machine to ensure that they made no local changes to 0.36.
  • If they didn't, a confirmation box, saying there's an update and showing the changelog, which we could provide on the site.
  • Then automatically download and place the old script into a /old/ folder. Or we could have a preference for this or a central management page?
 

fronobulax

Developer
Staff member
This sounds like an option, if the wheel is round enough, and suitable theres no point re-inventing it.
Commenting based upon my knowledge of SVN...

That the /dev/ version(s) of our scripts are kept however is best for the scriptwriters.

Absolutely. Developer needs some "process" to promote from developer's work and test space to SVN @ KoLmafia.us. Call that a developer making a "release".
The new versions could be uploaded to kolmafia.us/scripts/bumcheekascend.ash, and the old version then renamed to bumcheekascend-0.36.ash to allow for using old versions if necessary.
Renaming files is a bad practice with SVN as is incorporating version information in to the file name. (It is a practice I do not like in other contexts either but I digress...). I would trust SVN to maintain the previous versions and wrap SVN commands in such a way that the user could get the previous version without having to know about SVNs revision numbers.
An md5() check on the script on the users machine to ensure that they made no local changes to 0.36.
SVN will detect local changes and provides options to merge. I would definitely want to leverage these.
If they didn't, a confirmation box, saying there's an update and showing the changelog, which we could provide on the site.
SVN can diff between two versions which, given how lazy developers are about writing documentation, might be more reliable. It can also diff between "latest" and "local".
Then automatically download and place the old script into a /old/ folder. Or we could have a preference for this or a central management page?
SVN would download and overwrite. There is no benefit to keeping old copies except in two cases. One is when access to the SVN repository is interrupted. The other is when there are local changes to be preserved. In that case, it might be worth archiving what was there before a user requested update and merge was performed.

Bottom line - it still looks as if embedding portions of a SVN client in KoLmafia would be a good way to go.
 

bumcheekcity

Active member
Would embedding an SVN into Kolmafia be accessible to users with absolutely no knowledge of what that is?

If so, it sounds good, better than my suggestion.
 

Winterbay

Active member
I think I like this idea. Would I be correct in assuming that if you had access enough to upload scripts then you would have access to all of the repository? If so then two people collaborating on one script wouldn't be a problem (but may lead to short term vandalism if one is unlucky), but if you need to manage user rights on a per script basis then that would be a rather cumbersome task for someone I guess.

If there is an automated version (i.e. you opt out of any warning messages) I feel that a listing printed in the CLI at the end of logging in/breakfast of what scripts have been updated would be a good idea.
 
Top