Developers.UpdateProtocol: Difference between revisions
Jump to navigation
Jump to search
(Importing page from Tikiwiki) |
m (1 revision) |
(No difference)
|
Revision as of 20:09, 20 June 2009
Update Notification Protocol
An HTTP Request is sent out with two parameters:
- Version - the version making the request
- GUID - node's identifier, currently not used
Example: http://www.example.com/version?Version=1.2.3.4&GUID=00000010-0000-0010-8000-00FFBB335F5
The script produces a urlencoded response, consisting of keys and values. For example:
key1=value1&key2=value%20two
If no upgrade is needed, the script simply returns no upgrade keys/values (it can even return an empty response). If an upgrade is needed, these keys/values are usually included in the response:
- UpgradePrompt - message to display to user, usually lists some of the new features or important information
- UpgradeVersion - indicates the version the user is being upgraded to. This is a work-around for people who manually upgraded.
- UpgradeFile - what to name the download, eg "Shareaza_2.1.0.0.exe"
- UpgradeHash - the uppercase BASE32 encoded SHA1 of the file, with no URN prefix. For example "TLT5GBT6YX3GXDQM4AMSCAAAAAAAEKM"
- UpgradeSources - One or more HTTP sources to add to the download. If this is missing, the download won't have any initial sources.
- UpgradeTiger - the uppercase BASE32 encoded TigerTree root hash without prefix.
Some other useful keys that can be returned (with or without the upgrade keys):
- NextCheck - don't call back for N days, used to manage web server load
- AddDiscovery - can be used to feed new GWebCache URLs to clients.
- SystemMsg - print some text in the system/log window
- Message - show a plain MessageBox() style message (not an upgrade prompt)