Updaters should keep track of their own metadata and should not rely on the changelog files.
Put the RSS feed data into the zip pasta!!! Please!!! Right now WAU is doing it itself the files are tiny like <1k - you can take out filelist.wau, and name all the changelogs the same, and you have a consistant way of determining both local and remote versions.
No. Updaters should work even if I decide to remove changelogs from the zips entirely.
IIRC WUU uses a xml file in the root interface folder or in wow to keep track of addons and versions. rather handy when i reinstalled wow. i imported the xml/other file that wuu spit out and fwabam i got all my addons back..
i think the idea here as said is to have a unified consistant method to determin local and remote versions. the Method it'self i would think is irrelavant as long as it's aggreed upon.
In WUU, I pretty much take it for granted that if an addon isn't updated at least once from inside of WUU, I can't know the local version - there are probably ways to determine local version easily on WoWAce addons, but on other sites, it's impossible.
I can't run the .bat/.sh-files for extracting LoD addons directly, either - what would happen if someone on another site added a .bat file that was named like the LoD files containing "DELTREE /Y %APPDATA%", or something like that...
As OrionShock posted, the thing is that we need to find a unified way of doing stuff - I think maybe we should start from scratch on the file formats, to get rid of "old ideas" that complicate stuff.
Idea: How about we identify what parts of the "internals" need to be shared between WUU, WAU, and the other updaters posted in this forum (have any of them commented yet, by the way? I'm out of the loop :P) - stuff like "are we running no-ext or not?" "should LoD addons be split" "which (sub-)addon(s) should not be installed, even if they are part of a larger pack" "which addon(s) should be ignored by everyone/only WUU/only WAU/everyone but WAU?" "which version is the local addon X?"
Afterwards we define a new file format/several file formats for the necessary file(s) to contain this info (I'd like to XML most of it, but that's just me ;)), and implement it in a future (the next?) version of WUU/WAU/etc. with backwards compatibility (read old format+new format, but only write new format (and delete old files), or something like that)
im no Coder but i can Bull Shit something up to the effect of a standard like nothing else. so here is my 2c on the matter and to consolidate allready common ideas into one post:
-Considering the 2 following Stipulations--
1) The Standard will be used by more than one updater program. Currently being considered is WAU and WUU, but it would not be beyond the scope of the standard to extend to the programs used by World of War or CosmosUI Camps.
2) Considering that other updaters are simply interfacing with wowace as just another site rather than the only Line of Bizzness, Any form of executable / batch file cannot be included in the upacking or updating proccess, as this can lead to abuse.
2) Taking into Account the 2nd Stipulation, text coded files are the obvious choice of distributing / storing meta-data of any sort. XML has allready been mentioned as the format of choice.
----
1) Said XML file should include the following information for consistancy. Current Local Version (be it by SVN revision number or Date of Upload), Source of Addon and Particulars of downloading any sort of updates. Due to the Nature of Ace Framework based Addons some being Load On Demand or Modularized, should inlude the "Source Folder" to the Module, relavant to the \addons folder and the "Destination Folder" also relavant \addons. To Compermise with Pastamancer, this XML file should be local to the addon to allow for any setups, extras or specials. Changelogs shoule be considered independant to the updater and as just another file with the addon.
2) Conserning Libs - as Each Lib is, iirc, packaged to be it's own unique addon.
On files.wowace.com, Addons are Named as <Addon>.Revision.LibRev.zip where the Revision might not change but the Libs do, the updater might take this into special consideration and only update on a major revision change rather than a lib update. But, There is another directory / convention that WAU uses is to add "/no-ext/" to the dir path and grab the "With Out externals"-"Version". IMHO they are 2 differnet Addons and should be treated as such. The No-Ext version should have all the Libs listed as Dependancys because the addon will not function with out them. (The Viablity of the later idea is not yet been established).
3) Conserning SAL & Additional Information in the XML. Considering the special nature of the "StandAloneLibrarys" place holder. The XML fields should be allowed to Specify Externals not apart of the Central Addon and be able to list where the external can be downloaded from. This would account for the Strangeness that some of the CosmosUI addons do.
(god those ppl are weird)
.. those are the only things i could conjour up while at work..
Considering that inorder for this to work, we'd have to get the 4 other major addon camps to aggree, being Ui.WorldOfWar.net, www.Curse-Gaming.com, www.WoWInterface.com, www.CosmosUI.org, to include an .xml file in with their addons or generate it by the updater some how. WUU has the Functionality to grab addons from the various sites, so getting thats not a problem. It's the Modular Addons thats the problem.
For example, iirc, Deadly Boss Mods is a Modular addon but, it comes with all it's modules in the root of the zip file, and dosn't include a unpacking script of any sort. Also with Addon Collections, same thing, it's not one addon, it's many and differentiating the Modular Addons from the UI Packs when they look the same is gona be a pain.
Personaly, Changelogs are unique to the WoWCommunity because of the SVN, so IMHO it should not be covered nor touched by the updater and left up to the packing of the zip file, xpt for WAU becuase it's a sinle site program.
Its copied straight from the rss feed - it actually has nothing at all to do with WAU.
Why make a new format for this data when we have to read it on the feed too!? Just put this in the zip. I dont see why that is such a big deal, and it solves everything!
WAU basically has a 3rd feed which is all the local files concatenated.
IIRC WUU uses a xml file in the root interface folder or in wow to keep track of addons and versions. rather handy when i reinstalled wow. i imported the xml/other file that wuu spit out and fwabam i got all my addons back..
i think the idea here as said is to have a unified consistant method to determin local and remote versions. the Method it'self i would think is irrelavant as long as it's aggreed upon.
:D
WAU makes the same sort of files, and can restore from them. It just combines the feed data in each addon's folder to make a "local" feed, then gzips it.
Its copied straight from the rss feed - it actually has nothing at all to do with WAU.
Why make a new format for this data when we have to read it on the feed too!? Just put this in the zip. I dont see why that is such a big deal, and it solves everything!
WAU basically has a 3rd feed which is all the local files concatenated.
...I never said that wasn't going to be done :P I'll probably make "fake" RSS entries for the other sites I work on. The stuff I was talking about was the "instructions" to the updater ("no-ext this", "LoD that", "ignore those") - that's what we need to synchronize, preferably on a level where we can say "this addon is handled by WUU, but that addon is handled by WAU"
WAU uses this preference when doing an AUTO externals update of a local version with unknown origin, ie. if it can't find .source in the addon folder. This preference is not used for anything else. The user can choose to update WITH, WITHOUT, or AUTO externals. In the AUTO case it will update each addon against the the feed which matches its external status.
2) Addon unpacking
WAU has one global setting to enable or disable it from within the app. Then it supports per-addon settings via the .nounpack/.nopack folders. It also actually does not keep track of whether an addon is in the packed or unpacked state.
3) Don't update
WAU only supports .svn directories currently.
4) !!!SAL - Deprecated
WAU uses the dependency and provides info from the rss feed to ensure the correct libraries are installed.
1-WUU) WUU has an internal setting for "Use no-ext?" which is global for all addons handled by WUU (from WoWAce, of course) (stored in settings.wurm.xml in the WUU folder, for now)
2+3-WUU) WUU has the per-addon setting [Ignore] to just "don't touch" a local folder (Folders containing a .svn folder are automatically ignored), and the [Dummy] setting to tell WUU to not extract the (sub-)addon in question (so you don't have to have empty folders in your addons dir) (stored in addons.wurm.xml in the WoW folder, for now)
4) WUU has an internal setting "Extract LoD addons" (or "Handle Packages", as it's called in the new 1.5 beta) - this is modified by [Dummy]-addons, if applicable. (in settings.wurm.xml). LoD child addons are marked as "[Related]" to their parent addon.
5) As mentioned, WUU uses the file <addonname>.wuuver to determine local version - this file is written after the first update and is a flat text file, so the XML parser doesn't have to be invoked for version checks. I'll probably add a handler to use the RSS fragment in 1.7.
sylvanaar , RSS works. as long as it covers the other stuff mentioned.
also a common Naming / definitions needs to be established, and they need to be in such a way that it won't matter wether its an ace addon or not. the WAU methods seem to be very solid, but the same dosn't apply for the stuff in the wild :D
I wonder why the folders start with a dot... ( .pack .unpack ) .. guess thats to hide them in linux default ls ? but why ?
It's afaik even impossible to create folders starting with dot using windows explorer...
yes but you can go to Run command and type cmd to open a command window, navigate to the folder and type md .pack or whatever, if you can't use command window then.... oh well
I wonder why the folders start with a dot... ( .pack .unpack ) .. guess thats to hide them in linux default ls ? but why ?
It's afaik even impossible to create folders starting with dot using windows explorer...
yes but you can go to Run command and type cmd to open a command window, navigate to the folder and type md .pack or whatever, if you can't use command window then.... oh well
And that's faster / better / whatever then creating a folder with windows explorer ? So where is the advantage ?
It's not the question if I can do it or not.. it's more the question if the average wow player / addons user can do it.. and why he should be forced to do it that way. BTW, I have my own updater to keep my addons updated and apply my custom patches after updating. and it's creating an updater.cache file in the addons directory and obays a updater.ignore. It's not ignoring svn directories because I store my folder structure in svn (just the empty folder names) and some own addons complete.
Probably just for consistency with the .svn convention.
well.. svn can use .svn or _svn for it's directory (:
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.
Sharing preferences with WAU is useful to non-WAU updaters from a marketshare perspective. It means that it's easier for people to move to one of the alternate updaters. (Conversely, WAU, being the dominant updater, has no incentive to support other people's standards.)
I'm actually curious what proportion of the userbase each updater has. I assume that everyone is using a properly-set UserAgent, so log analysis might be able to shed light on this... :D
I believe the important thing is to simply make it so that updaters don't step on others toes. Using one shouldn't bork the functionality of the others.
Nicely said Kaelten : "I believe the important thing is to simply make it so that updaters don't step on others toes. Using one shouldn't bork the functionality of the others."
... ok so this thread finally went off in the direction i thought it would... :D
"Default Distribution" = The way the Zip file comes when a user or updater downloads off a given site, with out anything extra done to it.
Last night, brewing over this thread, I realized that there where a few addons that kinda stood out as far as how things are packaged and distributed. At least they stood out in my head. I came up with the following examples of rather common distribution type addons:
From Curse-Gaming: Deadly Boss Mods in Default Distribution is Modular by design in the root folder of the Zip file. the RSS/XML needs to account for this format of Distribution. this addon is considered complete as it has no req deps. (WUU seems to do a grate job at that already, so we prolly don't need to worry)
From ui.worldofwar.net/www.wowinterface.com: X-Perl while going to follow the same principal of DBM. Xperl has Optional Deps that need to be handled as far as source of where one can download the opt dependency and possibly from many sources. And because something like this would have to be compiled by the author or by a central repository or RSS feed for a site, must be taken into account that the opt deps might not even be listed in the rss feed.
From www.CosmosUI.org: PartyQuests in Default Distribution has Required Dependacys that MUST be downloaded in order for the addon to Function. Any and ALL required Dependancys should be listed in the feed and where to download them (mulitpal sources also be accounted for).
From files.wowace.com: Pitbull. ( <3 ck ) Pitbull in Default Distribution (with externals,not Unpacked, just un-ziping the file off of the files page like a normal person) is a whole and complete addon, with no option dependancys and simply the option to modularize the addon, and with embedded libs.
-Considering that the Addon by Default Distribution cannot operate with out it's libs either embeded or disembeded, an ace addon that has embedded libs is to be considered complete with no dependancys or optional dependancys, and that the libs should be left out of the RSS/XML file.
-Now for the modules the RSS/XML needs to define what folders are going to be moved and to where, shouldn't be that hard.
-For Ace Addons without Embeded libs, those libs MUST be listed as Required Dependancys and listed in the code file and ofc where to download. This has been accounted for already iirc by the updater rss, so converting it over to a common method shouldn't be hard. requiring the deps is done because that Addon cannot function at all with out it's libs, regardless if emb or dis emb.
--it seems that we've come to a casual understanding of what w're doing here.. would anyone be willing to type or conjour up a draft of said xml/rss file for the above addons as they are rather Archtipical of any addon you might see. That way we might start to hash out perticulars, i would but ive got to go to work soon IRL
-edited for sanity-
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo. Updaters should work even if I decide to remove changelogs from the zips entirely.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumi think the idea here as said is to have a unified consistant method to determin local and remote versions. the Method it'self i would think is irrelavant as long as it's aggreed upon.
:D
I can't run the .bat/.sh-files for extracting LoD addons directly, either - what would happen if someone on another site added a .bat file that was named like the LoD files containing "DELTREE /Y %APPDATA%", or something like that...
As OrionShock posted, the thing is that we need to find a unified way of doing stuff - I think maybe we should start from scratch on the file formats, to get rid of "old ideas" that complicate stuff.
Idea: How about we identify what parts of the "internals" need to be shared between WUU, WAU, and the other updaters posted in this forum (have any of them commented yet, by the way? I'm out of the loop :P) - stuff like "are we running no-ext or not?" "should LoD addons be split" "which (sub-)addon(s) should not be installed, even if they are part of a larger pack" "which addon(s) should be ignored by everyone/only WUU/only WAU/everyone but WAU?" "which version is the local addon X?"
Afterwards we define a new file format/several file formats for the necessary file(s) to contain this info (I'd like to XML most of it, but that's just me ;)), and implement it in a future (the next?) version of WUU/WAU/etc. with backwards compatibility (read old format+new format, but only write new format (and delete old files), or something like that)
Too much? :)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-Considering the 2 following Stipulations--
1) The Standard will be used by more than one updater program. Currently being considered is WAU and WUU, but it would not be beyond the scope of the standard to extend to the programs used by World of War or CosmosUI Camps.
2) Considering that other updaters are simply interfacing with wowace as just another site rather than the only Line of Bizzness, Any form of executable / batch file cannot be included in the upacking or updating proccess, as this can lead to abuse.
2) Taking into Account the 2nd Stipulation, text coded files are the obvious choice of distributing / storing meta-data of any sort. XML has allready been mentioned as the format of choice.
----
1) Said XML file should include the following information for consistancy. Current Local Version (be it by SVN revision number or Date of Upload), Source of Addon and Particulars of downloading any sort of updates. Due to the Nature of Ace Framework based Addons some being Load On Demand or Modularized, should inlude the "Source Folder" to the Module, relavant to the \addons folder and the "Destination Folder" also relavant \addons. To Compermise with Pastamancer, this XML file should be local to the addon to allow for any setups, extras or specials. Changelogs shoule be considered independant to the updater and as just another file with the addon.
2) Conserning Libs - as Each Lib is, iirc, packaged to be it's own unique addon.
On files.wowace.com, Addons are Named as <Addon>.Revision.LibRev.zip where the Revision might not change but the Libs do, the updater might take this into special consideration and only update on a major revision change rather than a lib update. But, There is another directory / convention that WAU uses is to add "/no-ext/" to the dir path and grab the "With Out externals"-"Version". IMHO they are 2 differnet Addons and should be treated as such. The No-Ext version should have all the Libs listed as Dependancys because the addon will not function with out them. (The Viablity of the later idea is not yet been established).
3) Conserning SAL & Additional Information in the XML. Considering the special nature of the "StandAloneLibrarys" place holder. The XML fields should be allowed to Specify Externals not apart of the Central Addon and be able to list where the external can be downloaded from. This would account for the Strangeness that some of the CosmosUI addons do.
(god those ppl are weird)
.. those are the only things i could conjour up while at work..
Considering that inorder for this to work, we'd have to get the 4 other major addon camps to aggree, being Ui.WorldOfWar.net, www.Curse-Gaming.com, www.WoWInterface.com, www.CosmosUI.org, to include an .xml file in with their addons or generate it by the updater some how. WUU has the Functionality to grab addons from the various sites, so getting thats not a problem. It's the Modular Addons thats the problem.
For example, iirc, Deadly Boss Mods is a Modular addon but, it comes with all it's modules in the root of the zip file, and dosn't include a unpacking script of any sort. Also with Addon Collections, same thing, it's not one addon, it's many and differentiating the Modular Addons from the UI Packs when they look the same is gona be a pain.
Personaly, Changelogs are unique to the WoWCommunity because of the SVN, so IMHO it should not be covered nor touched by the updater and left up to the packing of the zip file, xpt for WAU becuase it's a sinle site program.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is what's in the file:
Its copied straight from the rss feed - it actually has nothing at all to do with WAU.
Why make a new format for this data when we have to read it on the feed too!? Just put this in the zip. I dont see why that is such a big deal, and it solves everything!
WAU basically has a 3rd feed which is all the local files concatenated.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWAU makes the same sort of files, and can restore from them. It just combines the feed data in each addon's folder to make a "local" feed, then gzips it.
...I never said that wasn't going to be done :P I'll probably make "fake" RSS entries for the other sites I work on. The stuff I was talking about was the "instructions" to the updater ("no-ext this", "LoD that", "ignore those") - that's what we need to synchronize, preferably on a level where we can say "this addon is handled by WUU, but that addon is handled by WAU"
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) Default Feed (ext, no-ext)
WAU uses this preference when doing an AUTO externals update of a local version with unknown origin, ie. if it can't find .source in the addon folder. This preference is not used for anything else. The user can choose to update WITH, WITHOUT, or AUTO externals. In the AUTO case it will update each addon against the the feed which matches its external status.
2) Addon unpacking
WAU has one global setting to enable or disable it from within the app. Then it supports per-addon settings via the .nounpack/.nopack folders. It also actually does not keep track of whether an addon is in the packed or unpacked state.
3) Don't update
WAU only supports .svn directories currently.
4) !!!SAL - Deprecated
WAU uses the dependency and provides info from the rss feed to ensure the correct libraries are installed.
2+3-WUU) WUU has the per-addon setting [Ignore] to just "don't touch" a local folder (Folders containing a .svn folder are automatically ignored), and the [Dummy] setting to tell WUU to not extract the (sub-)addon in question (so you don't have to have empty folders in your addons dir) (stored in addons.wurm.xml in the WoW folder, for now)
4) WUU has an internal setting "Extract LoD addons" (or "Handle Packages", as it's called in the new 1.5 beta) - this is modified by [Dummy]-addons, if applicable. (in settings.wurm.xml). LoD child addons are marked as "[Related]" to their parent addon.
5) As mentioned, WUU uses the file <addonname>.wuuver to determine local version - this file is written after the first update and is a flat text file, so the XML parser doesn't have to be invoked for version checks. I'll probably add a handler to use the RSS fragment in 1.7.
It's afaik even impossible to create folders starting with dot using windows explorer...
Probably just for consistency with the .svn convention.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumalso a common Naming / definitions needs to be established, and they need to be in such a way that it won't matter wether its an ace addon or not. the WAU methods seem to be very solid, but the same dosn't apply for the stuff in the wild :D
yes but you can go to Run command and type cmd to open a command window, navigate to the folder and type md .pack or whatever, if you can't use command window then.... oh well
And that's faster / better / whatever then creating a folder with windows explorer ? So where is the advantage ?
It's not the question if I can do it or not.. it's more the question if the average wow player / addons user can do it.. and why he should be forced to do it that way. BTW, I have my own updater to keep my addons updated and apply my custom patches after updating. and it's creating an updater.cache file in the addons directory and obays a updater.ignore. It's not ignoring svn directories because I store my folder structure in svn (just the empty folder names) and some own addons complete.
well.. svn can use .svn or _svn for it's directory (:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThey were a quick solution, and there were only a couple packages at first anyways.
I added the .nopack as part of a concept i was playing with
http://www.wowace.com/forums/index.php?topic=6054.0
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.
Something like that
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMore importantly, why would anyone be using multiple updaters for their ace addons?
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://en.wikipedia.org/wiki/Collaboration
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm actually curious what proportion of the userbase each updater has. I assume that everyone is using a properly-set UserAgent, so log analysis might be able to shed light on this... :D
-
View User Profile
-
View Posts
-
Send Message
Curse Premium... ok so this thread finally went off in the direction i thought it would... :D
"Default Distribution" = The way the Zip file comes when a user or updater downloads off a given site, with out anything extra done to it.
Last night, brewing over this thread, I realized that there where a few addons that kinda stood out as far as how things are packaged and distributed. At least they stood out in my head. I came up with the following examples of rather common distribution type addons:
From Curse-Gaming: Deadly Boss Mods in Default Distribution is Modular by design in the root folder of the Zip file. the RSS/XML needs to account for this format of Distribution. this addon is considered complete as it has no req deps. (WUU seems to do a grate job at that already, so we prolly don't need to worry)
From ui.worldofwar.net/www.wowinterface.com: X-Perl while going to follow the same principal of DBM. Xperl has Optional Deps that need to be handled as far as source of where one can download the opt dependency and possibly from many sources. And because something like this would have to be compiled by the author or by a central repository or RSS feed for a site, must be taken into account that the opt deps might not even be listed in the rss feed.
From www.CosmosUI.org: PartyQuests in Default Distribution has Required Dependacys that MUST be downloaded in order for the addon to Function. Any and ALL required Dependancys should be listed in the feed and where to download them (mulitpal sources also be accounted for).
From files.wowace.com: Pitbull. ( <3 ck ) Pitbull in Default Distribution (with externals,not Unpacked, just un-ziping the file off of the files page like a normal person) is a whole and complete addon, with no option dependancys and simply the option to modularize the addon, and with embedded libs.
-Considering that the Addon by Default Distribution cannot operate with out it's libs either embeded or disembeded, an ace addon that has embedded libs is to be considered complete with no dependancys or optional dependancys, and that the libs should be left out of the RSS/XML file.
-Now for the modules the RSS/XML needs to define what folders are going to be moved and to where, shouldn't be that hard.
-For Ace Addons without Embeded libs, those libs MUST be listed as Required Dependancys and listed in the code file and ofc where to download. This has been accounted for already iirc by the updater rss, so converting it over to a common method shouldn't be hard. requiring the deps is done because that Addon cannot function at all with out it's libs, regardless if emb or dis emb.
--it seems that we've come to a casual understanding of what w're doing here.. would anyone be willing to type or conjour up a draft of said xml/rss file for the above addons as they are rather Archtipical of any addon you might see. That way we might start to hash out perticulars, i would but ive got to go to work soon IRL
-edited for sanity-