The muti-site stuff is beyond my scope. The wowace rss-data is good for WAU, so im thinking that you may want to have a schema for each site/source
One idea i was toying with for WAU was including the list of file contents WAU downloads for each addon. That would eliminate the need for deleting the addon folder during normal updating, as you would just remove the files.
When updating you could grab the list of installed local files, and compare it to the list of files in the updated version. Any file in the local list, but not in the updated list would get deleted locally - deleting directories as they are emptied.
This is pretty univerally useful, so i thought i'd give it a mention since "delete before update" does mess up user added/modified files. I have been debating should I turn on delete by default in WAU, but i much prefer this less drastic method for normal updates.
Doing this we can subtract the addon files, and leave behind something small enough to back up too. This would yield a addon "snapshot" + any extra files which were not part of the addons just save them together.
These snapshots are useful for other purposes as well. I know both WUU and WAU make them to some extent already. I'd like it so that someone could make a separate backup/restore utility, or a mod-pack compilation utility - utilizing the common data format.
I'd love to be able to let the user install WAU plugins which let them use some of the cool stuff peopl have written WAU could offer their functionality as addons to WAU (which would put them on the program menus) one that comes to mind : "Addon Folder Cleaner", or "Saved Variables Cleanup/Backup", "Filetype filter", etc etc. (This would require a repository of trusted addons of course)
The wowace feed needs a schema. I have a partial one i made, i'll post in a bit
I was thinking it might be a good idea to adopt some common conventions/standards for updater applications
...
To the other updater authors, would it be possible to agree on some sort of standard for the format and naming of these types of things.
Your Opening Post indicates that you'd like to create or colaborate about a "Multi-Site Unified Standard for Updater Programs"
Impliying it would be something that not only WAU can adopt but something that WUU can use, something that UICentral can use (http://wowui.incgamers.com/ui.php?id=2106), something that the Cosmos Patcher can use (http://www.cosmosui.org/distros.php).
So on your origional Premis of the Thread, Multi-Site handling is with in your scope as you are the one that opened the dialog. :D
The Logical Conclusion to any discussion of this type is that in the end it would be something that we, you , lejordet, would be able to contact other sites and attemt to sell / convince these sites to use.
Honestly this standard would benifit lejordet the most as his program is the ONLY program i know if that updates with many sites.
-----
in reponse to your Schema for the RSS feed, that Schema would have to be modifiyed to actualy have the full path for the file download to update, as well as taking into account changes in file name.
Im happy with using a common xml file to store everything.
I think we differ fundamentally on the way we handle ext/no-ext, but if the local version can be resolved that wont matter, so we could share that setting
As i have no implementation of per-addon or per-file exclusion, im happy to adopt anything (xml prefered)
I perhaps something like 1 file per site which contained the preferences? (any mirrors of the main site would share its prefs)
We could create subsections for per-updater unique settings, and the subsections would inherit the settings from the main section, and override them within thier subsection as well.
How about we have one file like that (I'd prefer to have the updater name in an attrib instead of it being the tag name, though - how about <updater name="WUU"></updater>? Also, while I'm 'attributing' stuff, how about <option name="unpack-packages">false</option> so we don't have to add tags for new settings (especially important if we use a DTD)) - let's say it's called "addonmanagers.xml" and put in Interface\Addons, and then another file (or files) to contain the per-addon settings?
It could be based on the WoWAce RSS format, but WUU's going to need a couple of fields more to "do its thing" ;)
Which brings me to:
Quote from sylvanaar »
The muti-site stuff is beyond my scope. The wowace rss-data is good for WAU, so im thinking that you may want to have a schema for each site/source
One idea i was toying with for WAU was including the list of file contents WAU downloads for each addon. That would eliminate the need for deleting the addon folder during normal updating, as you would just remove the files.
When updating you could grab the list of installed local files, and compare it to the list of files in the updated version. Any file in the local list, but not in the updated list would get deleted locally - deleting directories as they are emptied.
This is pretty univerally useful, so i thought i'd give it a mention since "delete before update" does mess up user added/modified files. I have been debating should I turn on delete by default in WAU, but i much prefer this less drastic method for normal updates.
Doing this we can subtract the addon files, and leave behind something small enough to back up too. This would yield a addon "snapshot" + any extra files which were not part of the addons just save them together.
These snapshots are useful for other purposes as well. I know both WUU and WAU make them to some extent already. I'd like it so that someone could make a separate backup/restore utility, or a mod-pack compilation utility - utilizing the common data format.
I'd love to be able to let the user install WAU plugins which let them use some of the cool stuff peopl have written WAU could offer their functionality as addons to WAU (which would put them on the program menus) one that comes to mind : "Addon Folder Cleaner", or "Saved Variables Cleanup/Backup", "Filetype filter", etc etc. (This would require a repository of trusted addons of course)
The wowace feed needs a schema. I have a partial one i made, i'll post in a bit
I've also been toying with the idea of tracking EVERYTHING that's installed - you just handle WoWAce, so you get all the "nicely formatted" addons ;) when handling Curse, it seems like every other addon has a new way of packing the files ("<addonname>\*.*" (as WoWAce), just having the files inside the ZIP with no directories, "ThisHereIsMyAddon\PutFilesInInterfaceAddons\MyAddon\*.*" (not exactly, but I've seen something like it)), so keeping a list of files would be quite useful ;)
Should we let the addon list file contain data for only the addons that are installed, or should every WoWAce addon be listed, in addition to every (seen) addon from Curse, etc.?
I've also been thinking of adding a way for users to add (cryptographically signed) Python scripts to WUU, to handle simple "one-shot" tasks like "Remove all changelogs from the addon dir", but realistically, that won't happen until we start on the beta after 1.6 stable :)
Also, big changes like this might take several versions to "get right", and we'll probably have to jump in with both feet when we get started (i.e. break backwards compatability at some point), but it'll be fun ;D I'm getting my Mac back today (I hope) so I can get the last parts of WUU 1.6 ready next week :)
I've also been toying with the idea of tracking EVERYTHING that's installed - you just handle WoWAce, so you get all the "nicely formatted" addons when handling Curse, it seems like every other addon has a new way of packing the files ("<addonname>\*.*" (as WoWAce), just having the files inside the ZIP with no directories, "ThisHereIsMyAddon\PutFilesInInterfaceAddons\MyAddon\*.*" (not exactly, but I've seen something like it)), so keeping a list of files would be quite useful
IMHO, provided a standard can be conjoured up, this type of problem will dissapate. Either the site would generate the RSS data, and the site would enforce a standard .zip file structure, or the site might foce the simmiting party to create the rss file themselfs; the first being eaisier and the later being a nightmare.
<insert an aggreement with iejordet's previos post..>
*also one last thing to consider and whine about, as we've experianced here with WAU and has been dramatized about with WUU and worldofwar.net, some sites might require an add of sorts to be displayed while being downloaded or displayed as part of adopting the standard for a given site... tho this might be bettere handled by the updater program itself and not this standard.
Honestly this standard would benifit lejordet the most as his program is the ONLY program i know if that updates with many sites.
Well, yes and no :) I know many people use WAU for the WoWAce addons, but WUU for the rest of the sites - something like this would be beneficial for "letting WAU keep its WoWAce market share" while increasing the WUU generic market share due to us reducing the chance of our updaters conflicting. Also, it would make it easier for users to switch between the two as needed.
WUU is the only updater (that I know of, at least) that handles multiple sites, yes, but that makes some of the code horribly complex due to there being no standards for addon .zip files :(
Honestly this standard would benifit lejordet the most as his program is the ONLY program i know if that updates with many sites.
Well, yes and no :) I know many people use WAU for the WoWAce addons, but WUU for the rest of the sites - something like this would be beneficial for "letting WAU keep its WoWAce market share" while increasing the WUU generic market share due to us reducing the chance of our updaters conflicting. Also, it would make it easier for users to switch between the two as needed.
WUU is the only updater (that I know of, at least) that handles multiple sites, yes, but that makes some of the code horribly complex due to there being no standards for addon .zip files :(
Ok..that came out the wrong way, I meant this but i said it the wrong way, it was unkind of me to say that considering what sylvanaar has done with WAU.
If this becomes Viable, it would convince the other sites to change the way the do things a little that would in the end make things better for users as things would become consistent. Even for those that want to update the old fashion way by downloading and upacking the zip, the file format would be similar between all addons.
Consider patch day, all anyone would need is to open An Updater, hit a few buttons and poof- everything is updated. No web based traffic for Images, XML BS, DB lag n' shit. then after the Patch Day Hell was over, things would go back to normal.
Another practical Example of this standard benefiting people, Guild Addon Compilations. Throw up an RSS of the Required Guild addons on the forums. then feed it into an Updater and you've got it all, no searching for the latest, or trying to figure out how to install it. just simple. UI Compilations, as the actual addon itself be just the /wtf/ folder, and the RSS has where all the addons are to install and directions on where to put the wtf files; it's a bit of a stretch albeit but it could work >.>
If this becomes Viable, it would convince the other sites to change the way the do things a little that would in the end make things better for users as things would become consistent.
sadly no. Looking forward, and with more knowledge, we're much more likely to have a hostile environment and competing standards. In fact its already headed that way.
If this becomes Viable, it would convince the other sites to change the way the do things a little that would in the end make things better for users as things would become consistent.
sadly no. Looking forward, and with more knowledge, we're much more likely to have a hostile environment and competing standards. In fact its already headed that way.
..."and to hell with the rest of the world." eh?
you present a rather pessimistic view on the matter Kaelten. It's rather childish for all-of-us, to suffer because the admins have a god complex about their web site, -not pointed at you. Tho your view is consistent with how the authors of KTM and Omen seem to just fling shit at each other in the curse thread, instead of pulling their collective heads out of their asses and doing something productive.
I guess asking for maturity in a Mob of People that seem rather intelligent is misplaced.
Kaelten seems to have given us our Final Opinion on the matter, being part of the Administrative Leadership of 2 of the 5 sites, id say that has some weight.
Then i bow out of this thread for good, no point in bumping a dead subject.
As far as the KTM vs Omen thing I've seen Antiarc try to be helpful. All I'm going to say about that.
As far as the sites issues go. Problem is money. People aren't doing this for free. In past efforts of collaboration ui.worldofwar.com has been unilaterally uninterested. One of the devs at curse and AL from cosmos got togather and piped up a standard of their own which I totaly disagree with as far as an updater standard. Its more applicable for sharing data betweens sites than updater usage. Wowinterface is fairly open to collaboration with others, and in all honesty so am I. At the same time I'm not likely to throw away our feed without a solid use case and reasoning.
As far as the KTM vs Omen thing I've seen Antiarc try to be helpful. All I'm going to say about that.
As far as the sites issues go. Problem is money. People aren't doing this for free. In past efforts of collaboration ui.worldofwar.com has been unilaterally uninterested. One of the devs at curse and AL from cosmos got togather and piped up a standard of their own which I totaly disagree with as far as an updater standard. Its more applicable for sharing data betweens sites than updater usage. Wowinterface is fairly open to collaboration with others, and in all honesty so am I. At the same time I'm not likely to throw away our feed without a solid use case and reasoning.
This isn't much about changing WoWAce as it is changing how the updaters use the information you provide, is it? :)
As far as I'm concerned, the RSS feeds you've got here are perfect for what I need - I just wish the other sites could adopt something simpler (like XML versions of the addon pages, so I wouldn't have to rely on screen scraping... /sigh) :)
the standard put between curse and cosmos is missing one thing, a zip location. This will let updaters 'in the know' find stuff but not others.
...you never sleep, do you? :P
I'm a bit out of the loop here; is this available in link form anywhere (or PM?), or is it "well, we could tell you, but then we'd have to block your updater first"? One goal with WUU is to use a minimum of bandwidth; scraping HTML isn't the best way of achieving that goal ;)
lol I do sleep 6-9 hours a night :) he (AL) had it on his personal server. I'm not sure of where to get the link now. But its more like a data serialization scheme than a updater's dream.
Kaelten, i aggree, the problems have always been money - Look at the Fiasco that WAU has turned into.. but finatial support is IMHO after the fact to a Common method to a Updater.
>>Theory
if a updater method could be aggreed upon for all sites. then a dialogue or aggreement could be made that the updater (*shudders* Prolly WUU, and as much as We/I/lejordet hate to sugest or listne to) could display an add from the appropirate site as it downloads / checks addons from each site.. or something to that effect. or cycles each week to another site. ew i feel dirty for just sugesting that.
Fk , with UICnetral if u log in, you get no adds, and i think that would be worth while to look into & consider
<<
but That will never happen if a common method cannot be aggreed upon, so it's more of an after the fact, that's why i'd like to conjour one up beofore considering ANY thing be changed.
Listen, i didnt mean "oh fu i dont care". What i am saying is that multi-site can't break single site or impose any restrictions on it - the pragmatic way would be to have a format relevant to each site then to map them to your own internal format. For instance if you use the wowace fields, then wowace only updaters will break when then encounter off-site links they cant do anything with.
I'm just sharing ideas, just imagine im saying "all updaters" when i say WAU. kk?
I just posted the stuff in response to "hey does anyone want to generate a starter schema". I just happend to have that one so i shared it.
And the configuration sharing format was more to illustrate the inheritance and scoping i was describing. I like <updater name=""> better too just takes more letters to type ;)
For the time being i am keeping the list of zip contents in its own file until we can iron out something. "ziplist.wau" in each folder - similar to filelist.wau.
The algorithm goes
1) Unzip to a temp dir, and have a list of the contents A including the folder name.
2) read ziplist.wau into another list B
3) iterate list B removing items which are also in list A.
4) Delete the any file which is still in list B
5) Get a list of paths in the addon's directory recursively as list C
6) Sort list C in reverse alpha order
7) Iterate list C, delete each folder if its empty
8) Copy the the contents of the new zip into the addon's directory
9) Add the new filelist.wau
Maybe I'm a bit confused here, don't you have to download and extract the ZIP file each time the addon is updated? Why would you need to keep a list of the zip file contents when you have to grab the ZIP file again, and have to iterate it's extracted directory structure to do the update?
Is the listing of the ZIP file contents for backup purposes?
I also think that adding the revision number to the .toc would remove the need for a lot of these little extra files. Or, why does the updater app not just add it's own meta info into the .toc?
Maybe I'm a bit confused here, don't you have to download and extract the ZIP file each time the addon is updated? Why would you need to keep a list of the zip file contents when you have to grab the ZIP file again, and have to iterate it's extracted directory structure to do the update?
Is the listing of the ZIP file contents for backup purposes?
I also think that adding the revision number to the .toc would remove the need for a lot of these little extra files. Or, why does the updater app not just add it's own meta info into the .toc?
1) WAU doesnt modify or read the TOC as a rule, so another file has to be used.
2) The contents of zip files can change, and there could be user files on the local machine. This has been an ongoing issue, which finally has been resolved.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOne idea i was toying with for WAU was including the list of file contents WAU downloads for each addon. That would eliminate the need for deleting the addon folder during normal updating, as you would just remove the files.
When updating you could grab the list of installed local files, and compare it to the list of files in the updated version. Any file in the local list, but not in the updated list would get deleted locally - deleting directories as they are emptied.
This is pretty univerally useful, so i thought i'd give it a mention since "delete before update" does mess up user added/modified files. I have been debating should I turn on delete by default in WAU, but i much prefer this less drastic method for normal updates.
Doing this we can subtract the addon files, and leave behind something small enough to back up too. This would yield a addon "snapshot" + any extra files which were not part of the addons just save them together.
These snapshots are useful for other purposes as well. I know both WUU and WAU make them to some extent already. I'd like it so that someone could make a separate backup/restore utility, or a mod-pack compilation utility - utilizing the common data format.
I'd love to be able to let the user install WAU plugins which let them use some of the cool stuff peopl have written WAU could offer their functionality as addons to WAU (which would put them on the program menus) one that comes to mind : "Addon Folder Cleaner", or "Saved Variables Cleanup/Backup", "Filetype filter", etc etc. (This would require a repository of trusted addons of course)
The wowace feed needs a schema. I have a partial one i made, i'll post in a bit
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://derey.home.mindspring.com/wowace-rss/
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYour Opening Post indicates that you'd like to create or colaborate about a "Multi-Site Unified Standard for Updater Programs"
Impliying it would be something that not only WAU can adopt but something that WUU can use, something that UICentral can use (http://wowui.incgamers.com/ui.php?id=2106), something that the Cosmos Patcher can use (http://www.cosmosui.org/distros.php).
So on your origional Premis of the Thread, Multi-Site handling is with in your scope as you are the one that opened the dialog. :D
The Logical Conclusion to any discussion of this type is that in the end it would be something that we, you , lejordet, would be able to contact other sites and attemt to sell / convince these sites to use.
Honestly this standard would benifit lejordet the most as his program is the ONLY program i know if that updates with many sites.
-----
in reponse to your Schema for the RSS feed, that Schema would have to be modifiyed to actualy have the full path for the file download to update, as well as taking into account changes in file name.
:D
How about we have one file like that (I'd prefer to have the updater name in an attrib instead of it being the tag name, though - how about <updater name="WUU"></updater>? Also, while I'm 'attributing' stuff, how about <option name="unpack-packages">false</option> so we don't have to add tags for new settings (especially important if we use a DTD)) - let's say it's called "addonmanagers.xml" and put in Interface\Addons, and then another file (or files) to contain the per-addon settings?
It could be based on the WoWAce RSS format, but WUU's going to need a couple of fields more to "do its thing" ;)
Which brings me to:
I've also been toying with the idea of tracking EVERYTHING that's installed - you just handle WoWAce, so you get all the "nicely formatted" addons ;) when handling Curse, it seems like every other addon has a new way of packing the files ("<addonname>\*.*" (as WoWAce), just having the files inside the ZIP with no directories, "ThisHereIsMyAddon\PutFilesInInterfaceAddons\MyAddon\*.*" (not exactly, but I've seen something like it)), so keeping a list of files would be quite useful ;)
Should we let the addon list file contain data for only the addons that are installed, or should every WoWAce addon be listed, in addition to every (seen) addon from Curse, etc.?
I've also been thinking of adding a way for users to add (cryptographically signed) Python scripts to WUU, to handle simple "one-shot" tasks like "Remove all changelogs from the addon dir", but realistically, that won't happen until we start on the beta after 1.6 stable :)
Also, big changes like this might take several versions to "get right", and we'll probably have to jump in with both feet when we get started (i.e. break backwards compatability at some point), but it'll be fun ;D I'm getting my Mac back today (I hope) so I can get the last parts of WUU 1.6 ready next week :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIMHO, provided a standard can be conjoured up, this type of problem will dissapate. Either the site would generate the RSS data, and the site would enforce a standard .zip file structure, or the site might foce the simmiting party to create the rss file themselfs; the first being eaisier and the later being a nightmare.
<insert an aggreement with iejordet's previos post..>
*also one last thing to consider and whine about, as we've experianced here with WAU and has been dramatized about with WUU and worldofwar.net, some sites might require an add of sorts to be displayed while being downloaded or displayed as part of adopting the standard for a given site... tho this might be bettere handled by the updater program itself and not this standard.
Well, yes and no :) I know many people use WAU for the WoWAce addons, but WUU for the rest of the sites - something like this would be beneficial for "letting WAU keep its WoWAce market share" while increasing the WUU generic market share due to us reducing the chance of our updaters conflicting. Also, it would make it easier for users to switch between the two as needed.
WUU is the only updater (that I know of, at least) that handles multiple sites, yes, but that makes some of the code horribly complex due to there being no standards for addon .zip files :(
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOk..that came out the wrong way, I meant this but i said it the wrong way, it was unkind of me to say that considering what sylvanaar has done with WAU.
If this becomes Viable, it would convince the other sites to change the way the do things a little that would in the end make things better for users as things would become consistent. Even for those that want to update the old fashion way by downloading and upacking the zip, the file format would be similar between all addons.
Consider patch day, all anyone would need is to open An Updater, hit a few buttons and poof- everything is updated. No web based traffic for Images, XML BS, DB lag n' shit. then after the Patch Day Hell was over, things would go back to normal.
Another practical Example of this standard benefiting people, Guild Addon Compilations. Throw up an RSS of the Required Guild addons on the forums. then feed it into an Updater and you've got it all, no searching for the latest, or trying to figure out how to install it. just simple. UI Compilations, as the actual addon itself be just the /wtf/ folder, and the RSS has where all the addons are to install and directions on where to put the wtf files; it's a bit of a stretch albeit but it could work >.>
sadly no. Looking forward, and with more knowledge, we're much more likely to have a hostile environment and competing standards. In fact its already headed that way.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium..."and to hell with the rest of the world." eh?
you present a rather pessimistic view on the matter Kaelten. It's rather childish for all-of-us, to suffer because the admins have a god complex about their web site, -not pointed at you. Tho your view is consistent with how the authors of KTM and Omen seem to just fling shit at each other in the curse thread, instead of pulling their collective heads out of their asses and doing something productive.
I guess asking for maturity in a Mob of People that seem rather intelligent is misplaced.
Kaelten seems to have given us our Final Opinion on the matter, being part of the Administrative Leadership of 2 of the 5 sites, id say that has some weight.
Then i bow out of this thread for good, no point in bumping a dead subject.
As far as the sites issues go. Problem is money. People aren't doing this for free. In past efforts of collaboration ui.worldofwar.com has been unilaterally uninterested. One of the devs at curse and AL from cosmos got togather and piped up a standard of their own which I totaly disagree with as far as an updater standard. Its more applicable for sharing data betweens sites than updater usage. Wowinterface is fairly open to collaboration with others, and in all honesty so am I. At the same time I'm not likely to throw away our feed without a solid use case and reasoning.
This isn't much about changing WoWAce as it is changing how the updaters use the information you provide, is it? :)
As far as I'm concerned, the RSS feeds you've got here are perfect for what I need - I just wish the other sites could adopt something simpler (like XML versions of the addon pages, so I wouldn't have to rely on screen scraping... /sigh) :)
...you never sleep, do you? :P
I'm a bit out of the loop here; is this available in link form anywhere (or PM?), or is it "well, we could tell you, but then we'd have to block your updater first"? One goal with WUU is to use a minimum of bandwidth; scraping HTML isn't the best way of achieving that goal ;)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium>>Theory
if a updater method could be aggreed upon for all sites. then a dialogue or aggreement could be made that the updater (*shudders* Prolly WUU, and as much as We/I/lejordet hate to sugest or listne to) could display an add from the appropirate site as it downloads / checks addons from each site.. or something to that effect. or cycles each week to another site. ew i feel dirty for just sugesting that.
Fk , with UICnetral if u log in, you get no adds, and i think that would be worth while to look into & consider
<<
but That will never happen if a common method cannot be aggreed upon, so it's more of an after the fact, that's why i'd like to conjour one up beofore considering ANY thing be changed.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm just sharing ideas, just imagine im saying "all updaters" when i say WAU. kk?
I just posted the stuff in response to "hey does anyone want to generate a starter schema". I just happend to have that one so i shared it.
And the configuration sharing format was more to illustrate the inheritance and scoping i was describing. I like <updater name=""> better too just takes more letters to type ;)
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumim going to bow out now for sure and watch what happens with this, as i have overExtended my skill-set in this regard.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe algorithm goes
1) Unzip to a temp dir, and have a list of the contents A including the folder name.
2) read ziplist.wau into another list B
3) iterate list B removing items which are also in list A.
4) Delete the any file which is still in list B
5) Get a list of paths in the addon's directory recursively as list C
6) Sort list C in reverse alpha order
7) Iterate list C, delete each folder if its empty
8) Copy the the contents of the new zip into the addon's directory
9) Add the new filelist.wau
Is the listing of the ZIP file contents for backup purposes?
I also think that adding the revision number to the .toc would remove the need for a lot of these little extra files. Or, why does the updater app not just add it's own meta info into the .toc?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) WAU doesnt modify or read the TOC as a rule, so another file has to be used.
2) The contents of zip files can change, and there could be user files on the local machine. This has been an ongoing issue, which finally has been resolved.