That's why I mentioned a weather plugin instead. Instead of using webparser for weather data and assigning each specific piece of information to a StringIndex number (which would change), the specific points of data, regardless of their arrangement, are assigned to a specific variable.
So if Tomorrow's Wind Direction was previously a StringIndex 7 and it's been changed to a StringIndex 9 in the new XML, the new XML or the new Rainmeter update would reflect that. Calling something like...
Code: Select all
[WeatherPlugin]
Measure=Plugin
Plugin=WeatherPlugin
[ChildMeasure1]
Measure=WeatherPlugin
Day=2
Info=WindDirection
would reflect the information from StringIndex 7 or StringIndex 9 depending on whichever version of the XML you currently have. If the version number of the XML file is out of date, and 7 is wrong, it will correct itself when Rainmeter restarts. Meanwhile ALL existing skins continue humming along as if nothing even happened. And now all existing skins using the WeatherPlugin would continue to have the correct data, even if the source of the weather data needs to change, the authors are calling by measure rather than regexp/stringindex, meaning that the weather data will always filter down to the skins and always be compatible with any changes, regardless of how the author has written their skin.
Right now I plan to host this xml file for my own use. I will use a webparser to access the xml content, then use another webparser to use the other webparser's string as its regexp, then use ambiguous [childmeasure1], [childmeasure2], [childmeasure3], etc. for each specific StringIndex child measure, and assign each StringIndex= a variable #TodayHighTemp#, #TomorrowHighTemp#, #TomorrowWindDirection#, etc.
Then I can assign strings like so...
Code: Select all
[TomorrowWindDirection]
Meter=String
MeterStyle=WeatherStyle
Text=[ChildMeasure#TomorrowWindDirection#]
Using another webparser, I gather the values of these variables that !WriteKeyValue if the version number has changed. So today it might look like...
TodayHighTemp=1
TomorrowHighTemp=4
TomorrowWindDirection=7
And tomorrow it could be changed to...
TodayHighTemp=2
TomorrowHighTemp=3
TomorrowWindDirection=9
By doing all of this I can guarantee that my skin will work with all current users even if the WebParser, Source, or arrangement of the StringIndex changes. Any changes made to the XML file will filter down to all existing users without needing to update their current version of the suite. When they connect to the internet, it will automatically !WriteKeyValue all necessary changes necessary to keep the weather skin working, even if the source of the data itself needs to be totally changed. This is the plan anyway.
I don't see why it wouldn't work. However, I'd prefer not to take this route. I really think implementing a solid solution for all users, new and old, is a beneficial pursuit for Rainmeter. Please please consider it. It's 1 man's work on a mothership XML that could prevent the same amount of work collectively for thousands of people, not to mention preventing hundreds of skins from spontaneously breaking on tens of thousands of computers.
All of the time you would spend occasionally updating an XML file would be mitigated by all of the time saved not needing to respond to forum threads from people wondering why their weather skin stopped working.