XML Files and Data Updates

[Paige]

I'd like to get your ideas on how to go about setting up an update
functionality and structure for the application.

Mainly, I realize that making a new build should only be for fixes,
not for data changes like new editions or sets being released by
Alderac. I'd like to have some sort of "Update me" button or function
that users can run and automagically download the most recent data
files, and/or install the most recent version of the program.

I think that moving all "data" to separate files will facilitate this,
but I don't know how to do it for the application files. Also, having
the data files in XML will allow a greater flexibility for expansion
later.

Thoughts?

*I would like to keep discussions from seeping their way into the
issue comments. Commenting on issues is fine, but lets use this group
to talk about broader issues.


Thanks,
Paige

[Bryan Buschmann]

Sorry about the issue comments thing.

The data file xml isn't too much of an issue as you say. We can use XML
for all of non-binary file needs and we can create a suitable
infrastructure for allowing clients to update the data files. As far as
updating the application files, well, that one's a bit trickier. It
depends on which tradeoff we want to make.

We can have an update check a flag on each of the files (checksum +
timestamp, etc) and if its not the latest version, it would download the
requisite file and overwrite the local copy. This would have larger
downloads and smaller patch times.

We could have a system that issues binary diff patches on each of the
files that are not the updated versions. This would be smaller downloads
but longer patch times. I would also assume that it would have more
complex coding requirements.

We could have a system that checks for installer version and downloads
and runs the installer entirely as well. It would be simpler in
execution, but much larger downloads and wouldn't support an "atomic"
upgrade method.

A couple thoughts as I sit down to come up with an xml schema...

Do we want a "hard typed" schema, ie:

<filter type="cardtype">
<type name="stronghold">
<displayName>Stronghold</displayName>
<deckType>Fate</deckType>
<goldCost>-</goldCost>
</type>
</filter>

Or a soft type schema, ie:

<filter type="cardtype">
<item name="stronghold">
<attribute name="displayName">Stronghold</attribute>
<attribute name="deckType">Fate</attribute>
<attribute name="goldCost">-</attribute>
</item>
</filter>

Another thought... What information do we need to have in the data files
to ensure proper operation with the application files? Do we need a
required version, data file version, or other flags that don't deal
explicitly with the data that we're storing?

-Bryan

[Bryan Buschmann]

I worked a bit on the settings XML file and dealing with XML parsing. I
can get EoPK to read and parse an XML equivalent of the eopk-settings
file. Really, not that hard on the input side. Output side has been
giving me a couple issues. The big one that I saw was that the
eopk-settings file is being re-written every time any one of the
settings change.

I was trying to figure out how to use the "OK" button on the preferences
UI to trigger a function but I've never worked with wxPython before so
I'm not sure what I should be looking for.

I can upload the new file to the repository if you want to take a look
at anything that I have. The only changes it requires to the rest of the
program is to comment out the "from settings import settings" instances
and add in "from xmlsettings import settings"

Let me know if you've got any ideas.

-Bryan

[Bryan Buschmann]

Ok, shook off the code fatigue from last night and worked some stuff
out.

We're using "from settings import settings" in a few more places. I
didn't look through all of the files. I had a misunderstanding that
import in python worked like include from PHP. I am seeing it in the
head of the following files:

canvas.py
dbimport.py
deckedit.py
EoPK.py
Kopia av canvas.py
playfield.py
settings_ui.py

I found what's causing the settings to be saved. settings_ui.py has
the class SettingsDialog which is binding the OK butting to
SettingsDialog.SaveSettings which is in turn calling .Save() on each
of the sub-sections of the preferences. .Save() on each of the sub
pages sets the variable data, which triggers a re-write of the entire
file. So, while its functional, we're writing to the disk 17 times
every time someone clicks OK on the Preferences dialog and as it
stands now, we'll increase the number of writes linearly with each
setting we add to the preferences file.

Am I being nitpicky, or should this be refactored? :-) Truth be
told... its bugging the hell out of me.

[Paige Watson]

No, not picky at all.  This should be refactored into a more simple updating model.  17 times is way too many, and there will be more options added.
Go ahead and see what you can do to simplify this.

I am still working on the double-click problem with attached cards.  I'll let you know how this works out.


I don't know PHP, so I can't compare the import to include functionality, but I believe that import actually copies the imported file contents to the current script file (unless it's been imported already by another script).  I'm not sure if this is correct, but this s my assumption.

[Bryan Buschmann]

I was able to knock it down to a single write when the settings change
within the Preferences Dialog.

I believe that there are places where the settings can change outside
the Preferences Dialog however. I'll have to do some digging to find
them. So for future reference, if you change a preference variable a
this time, it does not write to the file. You have to call
_XMLSettings.SaveSettingsFile() in order for it to actually write to the
disk. Perhaps I should rename it to .WriteSettingsFile()

There are some pretty big changes that I'm working on right now. I'm not
sure when you'd like me to check them in if you want to look at them.

-Bryan

Paige Watson wrote:
> No, not picky at all. This should be refactored into a more simple

> updating model. 17 times is way too many, and there *will* be more

[Paige Watson]

WriteSettingsFile() would be better.   Check them in when you get to a stopping point. Doesn't have to be totally done, just compilable.
You can also go to the code site and "request a code review" on your submissions and that should notify us of changes, etc.