As you all can see, the update system we have now is really not good enough.
A few years ago, I came up with a (imo) better system, that would be easy to work with and add to existing systems. It's based on xml files, and doesn't require a central server to work, or support from any big site, to be honest. It can easily be implented by larger sites like curse, if they choose to.
It does require that the addon developer can find some web space to put up a zip of the newest version, and a 200-500 byte file.
The basic idea is that there are one file in the addon directory called "update.xml" that programs get their data from. That file have information on the name of the extention, the author, version, and where to check for new versions.
The program reads that file, checks for update urls and check all urls for newer versions (that way a developer can put several links, in case one goes down).
If it finds a new version (and user selecs to update it), it gets the zip file urls from the server file, downloads the file, and unpacks it to the addon directory.
I've created some small proof of concept code and used an old addon of mine to show the concept.
the code is written in python, so should run on all modern operating systems (as long as python is installed). Just start the code/gui.pyw and select your wow directory.
It will scan all interface directories for update.xml and show the ones that have it. You can then use "Check for updates" to check if there are newer versions, and "Update" to update.
As an extra bonus, the server xml file holds enough info to download and install the addon, so I hope programs choosing to support this type of updates will also support auto install from the server xml file (which is why I gave it the .waui extention).
So, there it is. My old idea, which noone bothered with last time I presented it. I hope that the recent mess can make it clearer why such a system is needed. If anyone got any questions, please ask :)
Planning on making a DTD for the two xml files, thinking about optional fields.
Email should be optional, and there should be a field to tell if its beta. Required fields should be kept at a minimum, name of addon, author, version, and one update url should be minimum required. But there should be a set of optional fields too. homepage, email, beta, description (or maybe that should be required?), help url maybe.. hmm..
Any ideas for extra fields?
Planning to put up a page detailing a standard and maybe a reference implentation, and ask updater developers to add support for it. Who knows, if it gets widely supported, blizzard might decide to add support for it in the WoW client directly.
I like the idea, just like DataBroker aims to remove the reliance of the plugin on the display this would remove the reliance of the "update process" (from the perspective of the addon) on a specific updater.
So provided each updater gets changed to support such a system a user could choose updater purely by personal preference in specific functionality, not by necessity for addon X or Y, or library Z or so.
The idea is interesting. Having the update.xml inside the addon directory could allow to distribute it within the addon package, thus allowing a really centralized download location.
Now, call me pessimist but I doubt you could manage to have most addon sites adopt such kind of standard mainly because it doesn't address the bandwidth issue. I mean: what will be the advantage of an addon site to support such standard ? How could it help to pay the bandwidth bills ?
Edit: how do you handle required dependencies and no-lib mode ? ("no-lib" = what we used to call "without externals")
Moreover, this lacks a server-side API description. How does the updater detect new version ? How does it discover new servers ? And how does it ask for the addon list (for installation) ? etc...
In a way, I think it addresses the issue. As he said, an author can put as many links as he can for all the places where that file is available.
An updater could then choose randomly from which of those list of links (of course it already checked the version of the files [or the author updates his links if he has an update so as not to pull bandwidth from the sites]), and then the updater downloads and unpacks it.
So now, 100 users downloading, for example teksLoot, are downloading it from WoWI, WoWAce, Curse, WoWUI, teks' own repository. Assuming the distribution is divided equally, we have 20 downloaders for each site listed by tekkub.
It dispersed it. It is somewhat "decentralized" from the perspective of the system or the updater, instead of barraging WoWAce or WoWI or tek's repo by those 100 users.
The issue however, as was said, is having the addon sites adopt it. Secondly, they are still a business regardless, so all these addon sites are actually competing with each other. They'd rather have people downloading from their own site (like Curse) than let them download from WoWI...
Then we have the ADs.
It's a good idea, and I think it will work. Just have to be expounded, documented, and presented. Or maybe, build a new repo out of it ;) Make it a FLOSS, who knows what other ways it can be used out there in the wild.
I like the idea, just like DataBroker aims to remove the reliance of the plugin on the display this would remove the reliance of the "update process" (from the perspective of the addon) on a specific updater.
So provided each updater gets changed to support such a system a user could choose updater purely by personal preference in specific functionality, not by necessity for addon X or Y, or library Z or so.
Yes, that is exactly my goal.
Moreover, this lacks a server-side API description. How does the updater detect new version ? How does it discover new servers ? And how does it ask for the addon list (for installation) ?
The update.xml have one or more url's to an xml file that it will check against. The server xml will contain information about the latest version and where that can be downloaded. As for installation, this will not directly do that. It can however use the info from the server xml to ease the installation (one click install'ish).
Finding and displaying addons are already well solved by Curse and similar sites, the only thing this would do would be easing installation (from "download -> unpack to right dir" to "click - select Yes to dialog asking if you want to install <addon>").
As for why sites like Curse and similar would want to implent this.. Well, it's a feature. A feature that will attract users, which means more ads shown. Which is their ultimate goal :) People would still visit for finding addons, commenting, and all that. A site supporting an update standard that is also supported by most updaters is a good reason for people to use that instead of competing sites ;).
A feature that will attract users, which means more ads shown.
Only if this is the updater that shows the ads. If an user uses the updater, he won't visit the website anymore, so web ads become useless. That means you have to add an "ads url" field to the update.xml.
This is indeed an interesting idea. Call me a pessimist too, but I think that it will ultimately fall short, due to the business mindset of the various release sites.
Only if this is the updater that shows the ads. If an user uses the updater, he won't visit the website anymore, so web ads become useless. That means you have to add an "ads url" field to the update.xml.
IMO f that. Just grab a Ads URL from the major sites and throw it up around the updater box... it would look bad and people would hate it.. but would work.
I think that there are two reasons why this will still be a valuable system.
First of all, the system is designed not to rely on some central site. As long as addon author have a place where he can upload two small files (zip of latest version and a 300byte file), he can add support for it himself.
Secondly, if one site decides to add support for it, many users will change to that site, thus other sites will have a pressure on them to add support for it.
So, there's a chance that sites will use it, and even if they don't it's easy for an addon author to add support for it himself. So all in all, it's a worthwhile addition.
Secondly, if one site decides to add support for it, many users will change to that site, thus other sites will have a pressure on them to add support for it.
I don't know which site provided its own updater first but it effectively put pressure on other sites. But what those sites did ? They didn't provided compatible data (assuming they could ask the first site how to provide them) so an single updater could download all. No, most of sites created and provides their own updater.
Unless your system provides something really new and attractive from the point of view of a site owner, it will hardly spread.
It does have some good points to it. Firstly, it's simple to implent on a site. Secondly, the site doesn't have to (but can if they want) maintain their own updater program (and lets users select their own updater, which is added value).
If those reasons are good enough.. That's another matter.
The system could work. As the XML file is contained in the prepacked zip file. the Hoster would need to unpack the zip-file delete the xml file and repack it.
the Server.xml file doesn't even need to be hosted by the web-site hosting the addon. Think about it like a tracker for torrents. There is a single torrent tracker, but many independent torrent clients. Ther server.xml file could be hosted and updated by the author himself.
Maybe for major content patches the file could be aware of the API the addon was written for. As at the moment you need 3.0 for the PTR / Beta, but 2.4 for life.
Fields / Tags:
* none or more
+ at least one
Server.xml:
Name: a Unique name
Version the addon's version
WOW-LUA the WOW-API it is compatible to
Author*
Keywords*
Dependencies*
Details
URL+ download URL's
Client:
Name: like above
Version
Server-URL+: links to server.xml files
Dependencies*: so the local client is able to resolve dependencies for deleted addons
Reading up on the xsd documentation / tutorial(s) now. A wee bit overwhelming, but starting to get the idea.
essmene: great idea about lua api. When it comes to dependencies they should be both in server and update xml. Server have dependency, name, optional or required, and url to zip (or xml..) - client have dependency, name, optional/required. Sometimes an update introduces new dependencies :)
Nothing else yet, will add more tomorrow. Will probably set up a wiki or similar, and add some documentation.
Edit: An xml schema is a formal (very verbose) way of describing the format of the xml files. It will make it easier to work with them, and a computer can verify that they are correctly written.
A few years ago, I came up with a (imo) better system, that would be easy to work with and add to existing systems. It's based on xml files, and doesn't require a central server to work, or support from any big site, to be honest. It can easily be implented by larger sites like curse, if they choose to.
It does require that the addon developer can find some web space to put up a zip of the newest version, and a 200-500 byte file.
The basic idea is that there are one file in the addon directory called "update.xml" that programs get their data from. That file have information on the name of the extention, the author, version, and where to check for new versions.
The program reads that file, checks for update urls and check all urls for newer versions (that way a developer can put several links, in case one goes down).
If it finds a new version (and user selecs to update it), it gets the zip file urls from the server file, downloads the file, and unpacks it to the addon directory.
I've created some small proof of concept code and used an old addon of mine to show the concept.
The code you can find at http://home.broadpark.no/~junkyard/workman/example.zip and the addon at http://home.broadpark.no/~junkyard/workman/
the code is written in python, so should run on all modern operating systems (as long as python is installed). Just start the code/gui.pyw and select your wow directory.
It will scan all interface directories for update.xml and show the ones that have it. You can then use "Check for updates" to check if there are newer versions, and "Update" to update.
As an extra bonus, the server xml file holds enough info to download and install the addon, so I hope programs choosing to support this type of updates will also support auto install from the server xml file (which is why I gave it the .waui extention).
So, there it is. My old idea, which noone bothered with last time I presented it. I hope that the recent mess can make it clearer why such a system is needed. If anyone got any questions, please ask :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEmail should be optional, and there should be a field to tell if its beta. Required fields should be kept at a minimum, name of addon, author, version, and one update url should be minimum required. But there should be a set of optional fields too. homepage, email, beta, description (or maybe that should be required?), help url maybe.. hmm..
Any ideas for extra fields?
Planning to put up a page detailing a standard and maybe a reference implentation, and ask updater developers to add support for it. Who knows, if it gets widely supported, blizzard might decide to add support for it in the WoW client directly.
So provided each updater gets changed to support such a system a user could choose updater purely by personal preference in specific functionality, not by necessity for addon X or Y, or library Z or so.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNow, call me pessimist but I doubt you could manage to have most addon sites adopt such kind of standard mainly because it doesn't address the bandwidth issue. I mean: what will be the advantage of an addon site to support such standard ? How could it help to pay the bandwidth bills ?
Edit: how do you handle required dependencies and no-lib mode ? ("no-lib" = what we used to call "without externals")
Moreover, this lacks a server-side API description. How does the updater detect new version ? How does it discover new servers ? And how does it ask for the addon list (for installation) ? etc...
An updater could then choose randomly from which of those list of links (of course it already checked the version of the files [or the author updates his links if he has an update so as not to pull bandwidth from the sites]), and then the updater downloads and unpacks it.
So now, 100 users downloading, for example teksLoot, are downloading it from WoWI, WoWAce, Curse, WoWUI, teks' own repository. Assuming the distribution is divided equally, we have 20 downloaders for each site listed by tekkub.
It dispersed it. It is somewhat "decentralized" from the perspective of the system or the updater, instead of barraging WoWAce or WoWI or tek's repo by those 100 users.
The issue however, as was said, is having the addon sites adopt it. Secondly, they are still a business regardless, so all these addon sites are actually competing with each other. They'd rather have people downloading from their own site (like Curse) than let them download from WoWI...
Then we have the ADs.
It's a good idea, and I think it will work. Just have to be expounded, documented, and presented. Or maybe, build a new repo out of it ;) Make it a FLOSS, who knows what other ways it can be used out there in the wild.
Yes, that is exactly my goal.
The update.xml have one or more url's to an xml file that it will check against. The server xml will contain information about the latest version and where that can be downloaded. As for installation, this will not directly do that. It can however use the info from the server xml to ease the installation (one click install'ish).
Finding and displaying addons are already well solved by Curse and similar sites, the only thing this would do would be easing installation (from "download -> unpack to right dir" to "click - select Yes to dialog asking if you want to install <addon>").
As for why sites like Curse and similar would want to implent this.. Well, it's a feature. A feature that will attract users, which means more ads shown. Which is their ultimate goal :) People would still visit for finding addons, commenting, and all that. A site supporting an update standard that is also supported by most updaters is a good reason for people to use that instead of competing sites ;).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOnly if this is the updater that shows the ads. If an user uses the updater, he won't visit the website anymore, so web ads become useless. That means you have to add an "ads url" field to the update.xml.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIMO f that. Just grab a Ads URL from the major sites and throw it up around the updater box... it would look bad and people would hate it.. but would work.
First of all, the system is designed not to rely on some central site. As long as addon author have a place where he can upload two small files (zip of latest version and a 300byte file), he can add support for it himself.
Secondly, if one site decides to add support for it, many users will change to that site, thus other sites will have a pressure on them to add support for it.
So, there's a chance that sites will use it, and even if they don't it's easy for an addon author to add support for it himself. So all in all, it's a worthwhile addition.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't know which site provided its own updater first but it effectively put pressure on other sites. But what those sites did ? They didn't provided compatible data (assuming they could ask the first site how to provide them) so an single updater could download all. No, most of sites created and provides their own updater.
Unless your system provides something really new and attractive from the point of view of a site owner, it will hardly spread.
If those reasons are good enough.. That's another matter.
the Server.xml file doesn't even need to be hosted by the web-site hosting the addon. Think about it like a tracker for torrents. There is a single torrent tracker, but many independent torrent clients. Ther server.xml file could be hosted and updated by the author himself.
Maybe for major content patches the file could be aware of the API the addon was written for. As at the moment you need 3.0 for the PTR / Beta, but 2.4 for life.
Fields / Tags:
* none or more
+ at least one
Server.xml:
Name: a Unique name
Version the addon's version
WOW-LUA the WOW-API it is compatible to
Author*
Keywords*
Dependencies*
Details
URL+ download URL's
Client:
Name: like above
Version
Server-URL+: links to server.xml files
Dependencies*: so the local client is able to resolve dependencies for deleted addons
Maybe the three major repos won't use it, but that won't stop others from building upon it ;)
Reading up on the xsd documentation / tutorial(s) now. A wee bit overwhelming, but starting to get the idea.
essmene: great idea about lua api. When it comes to dependencies they should be both in server and update xml. Server have dependency, name, optional or required, and url to zip (or xml..) - client have dependency, name, optional/required. Sometimes an update introduces new dependencies :)
You can find them at http://waui.thelazy.net/xsd/
Nothing else yet, will add more tomorrow. Will probably set up a wiki or similar, and add some documentation.
Edit: An xml schema is a formal (very verbose) way of describing the format of the xml files. It will make it easier to work with them, and a computer can verify that they are correctly written.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium