Automatic Update System for Scripts

[Jakob Kummerow]

Hi,

thanks for your replies, both of you, Maciej and Peter.

> Out of curiosity - doesn't knewstuff2 (in kdelibs) already provide such
> facility (with gpg signing)?

> I was thinking of making GHNS support versioning

About GHNS/knewstuff2: Sure, that system provides an update mechanism,
including versioning support. (As far as I can see, that versioning
support is complete and working.)
There are two main differences to what I'm proposing:
- While the GHNS specification includes support for verification via
signatures, I have been unable to find an example (be it Amarok or
another app) that actually makes use of signed new stuff, nor have I
found any evidence whether/how that support is actually implemented in
knewstuff2. My little testing app contains a fully working, obligatory
signing system (i.e. signing isn't only possible, it's *necessary* for
any updates to be performed).
- As far I can see, GHNS/knewstuff2 is an *interactive* system, i.e.
users can click Tools -> Script Manager -> Get More Scripts, then
search the list for any available updates, and finally install these
updates, each one with an additional click. What I propose is to
completely automate this, i.e. upon application start, Amarok checks
for updates for scripts itself and applies them, without any user
interaction.

Again, when I wrote the updater, what I had in mind were Amarok's
supplied scripts (especially the lyrics script, given how many updates
it has needed in the past weeks), but the updater works for any
third-party scripts just as well. I haven't tested this, but I'm sure
it would even be possible to install an additional scripts using GHNS,
then have updates auto-applied to it, and finally uninstall it again
using GHNS (because the uninstall method in ScriptManager.cpp simply
deletes the script's directory, no matter what's in it). So, from a
usability point of view, I believe an automatic updater would be a
good supplement to the GHNS system. You could say that the automatic
updater is most suitable for important/critical updates that should be
deployed as quickly as possible (say, security patches or fixes for
grave bugs).

> the signature stuff is good, and the version info can be provided in the
> script.spec file.

Well, if you think that's more elegant... Parsing the first line of
main.js is easy to do, and main.js most probably is the one file
that's changed in the event of an update anyway, that's why I chose to
integrate the version information there, but of course it would be
just as easy to parse script.spec instead.

> All we need is [...], and most hard thing: to inform the script writers.

As I said: it's not necessary to deliver each and every update
automatically, so it doesn't really matter if script authors only get
the message one by one over time.
I'm sure you don't need me to tell you this, but I think the release
notes for a new Amarok version would be a prominent place to announce
such information.

> I like the idea of making all default script accessable without root access.

I had another idea about this: so far, every script gets copied to the
user's directory before any update checks are performed. But now I
think that's not even necessary, it would be sufficient to only put
updates (if and when they have been downloaded) to the user's
directory, and use the default scripts from /usr/share/... otherwise.


In order to be able to test my code inside Amarok itself, I still need
answers to at least this one question I asked in my first mail:
Is ScriptManager::findScripts() executed exactly once, namely on
Amarok startup? If yes, I'd tentatively integrate the new code there.
If no, where else should I integrate the code?

Thanks again, and best regards
Jakob