Ok, so this is a wrap-up of the auto-update strategy discussion in radio-dev.
Currently, the updating feature, as built in activeRenderer and liveTopics offers an update option in the Tools menu, plus an auto-update on startup user modifiable preference. It's on by default in aR, off by default in liveT. The updating feature relies on a Frontier master server operated by Paolo Valdemarin's eVectors.
We (meaning Paolo and I) thought it would be cool to provide this update facility to all tool developers free of charge, using a basic toolkit I developed on top of Simone Bettini's initial design. We'd like to find out if a Frontier/Radio tools market may exist some day, so in exchange for the updating service, tool users must register their copies on eVectors' server.
As far as aR is concerned, registration is free.
As pointed out by Jake Savin, the updating feature leverages Frontier's mainResponder subscriptions system, the same system used by Radio itself.
Both Jake, and eVectors' Andre Radke have separately reminded me of 2 very important rules UserLand adheres to
As a consequence, we will NOT tinker with the mainResponder code, as it would irresponsably put one of Radio's main and cleverest functions at risk.
End of contextual information, back to updates.
We (meaning Matt Mower and I) would like to design an update function for Radio tools with a little more flexibility than just a choice between update or don't update. To keep things simple, we'd like to provide the user with some information of what will happen during the update :
Which parts are fixes to known bugs that should be applied.
Which parts are new functions in a beta testing stage, that only dedicated testers or adventurous users should try.
Which parts are new functions considered stable.
What portion of the update process, if any, is done in a complete automatic mode should be left to user modifiable preferences, the default values depending on each developer's choice.
In addition - this is a new contribution - I think we need the latest update to be completely reversible (as in 'Undo update' menu option).
I'm tired of reformating this text in the moronic Yahoo Groups HTML form, so I'm moving this text to a story on my weblog at http://radio.weblogs.com/0104487/outlines/autoUpdates.html, please check it out there, and come back to the Yahoo discussion to contribute. In my opinion, the safest way of implementing an expanded update feature is through an additionalXML-RPC invokable method on the server side.
We need first to figure out how to store the parts meta data on the server.
Then how to query this data, present it to the user in a consistent way, and ultimately how to instal the requested parts.
Since Matt kind of initiated this discussion, I suggests he takes over from here :-) ( I actually have a meeting to run), but everybody's input is valuable.
