[jsword-devel] Module change detection

[Chris Burrell]

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.

It would make sense that if we show a change, we show the release notes
relevant to those changes at the same time.




On 16 July 2013 16:30, DM Smith <dmsmith at crosswire.org> wrote:

> Hi,
> 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.
>
> There are several parts to this:
> 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.
>
> Two solutions come to mind: different download repositories for different
> remotes or modify the conf of downloaded modules to note where they come.
>
> 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.
>
> The wiki has clarified that a conf change merely increments the final
> digit and that there are no module changes.
>
> 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.
>
> Putting this together:
> 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).
> b) we need to be able to determine that a module upgrades/obsoletes a
> module in the repository.
> 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.)
> These changes would go into o.c.j.book.install.Installer and
> InstallManager.
>
> The usage of these can be exemplified in o.c.j.bridge.BookInstaller.
> Scenarios:
> Get a list of installed books that have a Major Change.
> Get a list of installed books that have upgrades (are replaced by a module
> marking the installed one as obsolete).
>
> Is there anything else that would be helpful to have?
>
> In Him,
>         DM
>
>
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20130716/cc2baddb/attachment.html>