<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-12-23 17:50 GMT+01:00 Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hm... But they are the only way to figure out whether two resources are the same. If the md5sums don't work, we've got a bigger problem!<br>
<br>
Right now, the actual details have gone quite fuzzy in my mind, and I'm trying to focus on fixing the shortcuts/menu mess, so it's kind of hard to figure out what's up.</blockquote><div><br></div><div>So, yesterday i took a look at the issue and this is what's happening:</div><div><br></div><div>1) Resources, if modified and bundled, hadn't their md5 recalculated (but this is fixed by Wolthera patch here <a href="https://git.reviewboard.kde.org/r/121664/">https://git.reviewboard.kde.org/r/121664/</a>).</div><div><br></div><div>2) MD5, sometimes, are calculated on different "parts" of the resource, when loading and when saving.</div><div><br></div><div>3) Some resources (like KoSegmentGradient) when they get loaded in memory contains different values from the loaded file, so that when they are saved, even with no modification, the resulting files are different.</div><div><br></div><div>Wolthera, Sven, Tyyppi, and me had a long talk about this, clearly for problem 2 the solution is that md5 has to be calculated on the same thing, so either the file or the in memory representation.</div><div>Though point 3 makes the in memory representation not feasible for md5, because it may change from user to user and even for the same user (KoSegmentGradient lose information/precision when reading the file and can never save, even if unmodified, the same file).</div><div><br></div><div>So i think that for problem 3 we have three ways:</div><div><br></div><div>1) Either fix the classes to have only deterministic parts (but this might not be always possible given what the resource is and has to do) or calculate md5 on something that we are sure that it's not "interpreted" (but again this might no be fully possible if those parts doesn't change when the resource really change).</div><div><br></div><div>2) Implement a dirty bit in every resource and when creating bundles, if a resource that the user want to add to a bundle is modified, ask to the user which version of the two (original file, or the in memory modified version) he wants to add.</div><div>So if the resource is unmodified the original file will be copied into the resource bundle (right now is saved instead), if it's modified the user will choose and the file will be saved into the resource bundle only if the user chooses the modified version.</div><div>This way the md5 should be always calculated on the file, that is, afterall, the medium that can't change when given to others.</div><div><br></div><div>3) This is like solution 2 but without having to ask anything to the user. So for the case where the file is modified we automatically choose to use the modified version and to save it into the bundle.<br></div><div><br></div><div>2-3 Though do no solve the problem that arise when there's no original file, so when the resource is only in memory and it's representation can be different (when the resource is reloaded), from user to user. I think it's not solvable if not doing something like in point 1, or simply being sure to have files for everything.</div><div><br></div><div>What do you all think?</div></div></div></div>