Well, there was much talking and arguing there, but not much really done. I started in a new job, had too little time to do anything about it, and after a while I forgot about it. I see the discussion have flared a bit up again now and then there, but it's still only discussions.
I've had some vacation time now, and late last week I came over some of the old proof of concept code I wrote some years ago. I started fiddling with it, and managed to create a full program out of it (a bit basic, but have all the required stuff), and even made a windows installer for it.
I also put up a google code project for it. Code, information and install file can be found at : http://code.google.com/p/wow-au/
Eventual problems can also be reported at the Issues section of that site. If you have any feedback, thoughts or ideas, I'd very much like to hear them :)
It is a decent idea, and one I am considering. However, it's a very complex solution (both to implent and for the enduser), and generally not needed on the small / non popular addons.
I have some other ideas to cut down on bandwidth, for example using compressed diff's or a binary diff, and support for multiple, redundant download locations.
The concept is still evolving in my mind, a good night's sleep really helped.
A few additions to the current info:
server.xml
- Under update, also support patch tag. This holds the url to a zipped diff from given version to newest version. Patch tag have a "version" attribute. - This should save bandwidth.
-change type from "Beta, Release" to "Beta, Minor, Major". Lets users chose to only update to major versions (minor would be translation / text update and similar small stuff).
-Information, support a changelog tag. Holds url to a changelog.
update.xml:
-update url have attribute "major, minor, beta". So updater can select to only check update for one type.
Furthermore, the updater should use http HEAD to find out if file have changed since last time it checked. I also contemplate adding support for a "check interval" on the server xml. That combined with head and categorization of major, minor, beta server xml's should further minimize overhead bandwidth.
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.
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 :)
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.
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.
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 ;).
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.
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 :)
0
Well, there was much talking and arguing there, but not much really done. I started in a new job, had too little time to do anything about it, and after a while I forgot about it. I see the discussion have flared a bit up again now and then there, but it's still only discussions.
I've had some vacation time now, and late last week I came over some of the old proof of concept code I wrote some years ago. I started fiddling with it, and managed to create a full program out of it (a bit basic, but have all the required stuff), and even made a windows installer for it.
I also put up a google code project for it. Code, information and install file can be found at : http://code.google.com/p/wow-au/
Eventual problems can also be reported at the Issues section of that site. If you have any feedback, thoughts or ideas, I'd very much like to hear them :)
0
I have some other ideas to cut down on bandwidth, for example using compressed diff's or a binary diff, and support for multiple, redundant download locations.
0
The concept is still evolving in my mind, a good night's sleep really helped.
A few additions to the current info:
server.xml
- Under update, also support patch tag. This holds the url to a zipped diff from given version to newest version. Patch tag have a "version" attribute. - This should save bandwidth.
-change type from "Beta, Release" to "Beta, Minor, Major". Lets users chose to only update to major versions (minor would be translation / text update and similar small stuff).
-Information, support a changelog tag. Holds url to a changelog.
update.xml:
-update url have attribute "major, minor, beta". So updater can select to only check update for one type.
Furthermore, the updater should use http HEAD to find out if file have changed since last time it checked. I also contemplate adding support for a "check interval" on the server xml. That combined with head and categorization of major, minor, beta server xml's should further minimize overhead bandwidth.
0
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.
0
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 :)
0
If those reasons are good enough.. That's another matter.
0
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.
0
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 ;).
0
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.
0
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 :)