<div dir="ltr">We need to identify which modules are no longer allowed (not necessarily that we would delete it from the user, but so that web interfaces can adjust what they are showing.<div><br></div><div>It would make sense that if we show a change, we show the release notes relevant to those changes at the same time.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 July 2013 16:30, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
I think we need to add module change detection to JSword. Currently BibleDesktop uses the date of the module's zip. This is not good as sometimes it changes for no good reason.<br>
<br>
There are several parts to this:<br>
1) Knowing from which repository a module comes. Right now, we have one download location for modules, but we have the notion of multiple module locations. SWORD also has the notion of a master module repository. SWORD apps will download to that one location. So if the user has Eloquent, Xiphos, BibleTime, ... the modules will be mixed into the one location. The problem with this is that if two repositories have the same "name" for the module then there will be clashes. To date this has not been a significant problem.<br>
<br>
Two solutions come to mind: different download repositories for different remotes or modify the conf of downloaded modules to note where they come.<br>
<br>
2) Originally, the Version field of the module's conf was a 2 part decimal number. This is what JSword originally supported. Now, it can be a three part number. Note: Some instances in the wild have it as a non numeric. These are not in the CrossWire repository.<br>
<br>
The wiki has clarified that a conf change merely increments the final digit and that there are no module changes.<br>
<br>
3) A new module might obsolete an older module. In this case the module conf's Obsoletes field will indicate the [NAME] of the module. There may be good reasons to retain the older module.<br>
<br>
Putting this together:<br>
a) we need to be able to compare two Version strings to determine: No change, Minor change, Major Change. (Right now it detects Change/No Change).<br>
b) we need to be able to determine that a module upgrades/obsoletes a module in the repository.<br>
c) we need to be able to determine to which repository the above applies. (Excepting the "beta" repository, a module from one repository should not slam one from another.)<br>
These changes would go into o.c.j.book.install.Installer and InstallManager.<br>
<br>
The usage of these can be exemplified in o.c.j.bridge.BookInstaller.<br>
Scenarios:<br>
Get a list of installed books that have a Major Change.<br>
Get a list of installed books that have upgrades (are replaced by a module marking the installed one as obsolete).<br>
<br>
Is there anything else that would be helpful to have?<br>
<br>
In Him,<br>
DM<br>
<br>
<br>
<br>
<br>
<br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div><br></div>