This PR is likely to not merge cleanly with #372 as they touch common areas in the XML handling classes. I would suggest that this is held, possibly for rebasing until after that PR is merged.

#372 is now merged, looks like this needs some conflicts resolved.

I'm not sold on this. It means that any developers using a newer version of Mudlet will be spamming people who are using older versions of Mudlet even though they adjusted for it in the code.

I don't see a good solution to that and I don't see this fixing a concrete problem were are having?

This is a preventative measure! It is to prevent future versions of Mudlet silently messing things up in this version should some future archaeologist try using a later format file with something as ancient (to them) as the code at the point the check is put in (now, or hopefully soon). We have been using MudletPackage version=1.00 for a very long time and I suspect there has been changes over time but currently, with no checks there is no prevention/detection mechanism against future modifications in save files hitting current revisions. At the point where a version increment is contemplated, migration strategies can be considered (in the same way that the current release_30 branch code-base allows the use of the new area/map User Data feature but warns if the map format to use on save is not updated from the current 16 default that the current 2.1 release uses to the required 17).

This does not stop the user attempting to load a too new profile save file but it at least gives the user warning that things are amiss, Cf. the version checking done for the map save file which has, admittedly mutated much more over time...

Interestingly I was digging in the past recently to examine how the toolbar/menu/button code worked back in the era of Mudlet 1.0 - I was cautious and moved the contents of my present ~/.config/mudlet/ elsewhere and left an empty directory in its place - this was just as well as the profile save/load was quite different back then and I think it would have trashed my existing system/profiles - I didn't have the inclination to see what would have happened if I hadn't backed-up/protected it but I wonder what the 1.0 version would have made of a current setup... 😲

I understand it let's them load it, but like I said, any developer who makes a Mudlet package on Mudlet N+1 and makes sure it runs on Mudlet N fine will be spamming their users when they import the package because Mudlet N will say "this package was made on Mudlet N+1, watch out, might not work".

People will know things are amiss when they don't work, I don't see this adding value. Being chatty is not good, people just want to play the game, not read warning messages. Am I misunderstanding?

It should not be an issue because I do not anticipate that we will modify the XML format - in an incompatible way at all frequently - I do not expect to be in "new Mudlet version" ==> "new Profile XML format" cycle - I just want to cover ourselves should it become necessary.

For instance our current way of storing variables in the XML format is rather inefficient (I'm currently maintaining a copy of a 8000-ish room map's room descriptions as a Lua table and it bloats my save files to over 10MB but with a redesign I knocked it down to 3.8MB) just by restructuring that part of the XML format better - but it was incompatible with the current format so it is just a prototype at present and may not make it out of my system... - if it ever did, the new Mudlet that supported it must have a way to produce the old format for a version (or more) to maintain backward compatibility but that does not help if there is no mechanism to cleanly TELL the user that there is a problem with the saved profile if they are using an older version.

Despite past behaviour 😜 I do not want to spam people's console unnecessarily and I do not expect to cause the code here to be triggered any time soon but I would like it in place in Mudlet versions out in the wild for if/when we need it.

Well what would they do otherwise when something doesn't work? 🤷‍♂️

This proposal, reporting the versions that the particular Mudlet Application version can handle and what it is seeing {the proposed code at the moment only gives the latter, so we could assume 1.000 for the former} gives a meaningful message to report; rather than the user having to give a general (and possibly version dependent) "it does not work" situation report - on the forum or anywhere else that help might be sought.

Perhaps it is possible to reduce the size of the message - if that is felt to be over large?

IMO It gives the user a meaningful "thing" to report if they are having a problem - and perhaps its absence in a problem situation can also improve on the overall user experience - if something is wrong I think most people would prefer even a semi-cryptic error message than just a general "not working right" response.

Will I have to add an option to turn this on (or even off 😕)?

"if something is wrong I think most people would prefer even a semi-cryptic error message than just a general "not working right" response."

How can you guarantee is something is wrong? It could be right. It could come from a newer Mudlet and still work fine.

Sure, if you do an analysis on the code and you with 100% certainty know it will not work and something is wrong, I'm all for it. But this will have so many false positives that the warning messages will becomes useless and thus meaningless.

@vadi2 I realise that we are about to put together and set 3.0.1 loose and that may be the next "long-term" version (depending on how long it takes to get 4.0.0 ready and whether any show-stopping changes happen in any MUD that we have traditionally worked with) I am still of the opinion that we should include a version check in the current code so that if we ever have to break the way we structure the XML data in the certain knowledge that it cannot be handled satisfactorily in a way by the current code then we have a clean way to stop it being used and to force the user to seek an updated version of Mudlet.

I realise that it is a ☢️ nuclear option and not something to be used on a whim, but if the user uses an XML file which does carry a <MudletPackage version="2.0"> entity at the start I would rather they get a clear "This version of Mudlet cannot understand that XML file as it is from a later version and is incompatible" message rather than it making what will clearly be a half-hearted and error ridden attempt to parse it.

Two possible future developments that may require such shenanigans are:

• The XML format for storing variables is less than perfect as the key and variable "type" fields are stored as sub-elements that have to be parsed before the data for those are read:

    <Variable>
        <name>disableModule</name>
        <keyType>4</keyType>
        <value></value>
        <valueType>6</valueType>
    </Variable>
  

it is cleaner, more compact and easier for both humans and a machine parser to read the meta-data as attributes rather than sub-elements:

    <Variable name="disableModule" keyType="4" valueType="6">
        <key />
        <value />
    </Variable>

{I included an empty "key" sub-element in case there are other variable formats that need it but I am not sure it is needed} it might be feasible to go to the even more compact:

    <Variable name="disableModule" keyType="4" valueType="6" />

or, for a non-empty value the more realisitc

    <Variable name="disableModule" keyType="4" valueType="6" >Somthing</Variable>

and as a recent test case with prototype code to do this I managed to shrink my current 10MB WoTMUD game save file down to under 4MB with just this revision but it is of course incompatible with the current format...}

• I have plans to allow for the export of Mudlet map data as XML - whilst this uses more native storage space than the binary format that we currently use for saving/loading map data this would be done in conjunction with extending the XML importer to save/load all the stored map data that Mudlet handles/uses. The current XML parser is only complete enough for the form that IRE produces but it is not good enough IMHO to allow users to prepare data that they have extracted from other MUD clients to easily squirt it into Mudlet - and it is not publicly/F.O.S.S. spirited of us to prevent them taking data they have generated to use elsewhere (without having to write/source lua scripts to gather/generate an XML file themselves assuming that they can gather all the data from Mudlet Lua commands)! Anyhow, with that as a bit of an aside I can see that it might well be feasible for MUD operators to provide a single, all in one XML file that contains both a module GUI/system AND a basic/base map without having to contact the MUD server to download it - however that again is not something that I think the current system could support...

tl;dr; Please can we have into the current code base ASAP: a version check introduced and parsing be aborted should the XML file being read contain a <MudletPackage ...> element and that a version attribute, if present, has a string value, when converted to a float, greater than 1.000f? This is with the understanding that the version will not be incremented in this manner without consideration of what the effects will be on existing Mudlet versions and users...

Bother, posted this initially into wrong PR commentary...

The codebase has advanced so much that it will be easier to restart from later code as I have for #870 to the (now release_3_0_1) - closing #370 in the same manner as I will close this one, once that 870 gets sorted.

Rendered obsolete - code has gone into release_30 branch which is to be merged into development...