[sword-devel] Architecture and issues reporting

[Jaak Ristioja]

On 19.02.2017 17:28, David Haslam wrote:
> Many of the front-end developers get frustrated when users report software or
> module issues that are not caused by any fault in the front-end program.
> 
> Here in this mailing list, most of us are very familiar with the back-end /
> front-end architecture of our Bible software, yet even when relatively new
> users begin to understand this, it's still not that simple for them to
> distinguish symptoms due to a back-end bug and those due to a front-end bug.
> 
> Likewise to judge when a bug is in a module rather than in our software.
> 
> I feel that we could do with some worked examples in the developers's wiki
> that will aid users in terms of reporting issues.
> 
> Please comment and discuss.

+1

I think if the back-end common to all front-ends would reject buggy
modules (e.g. pass/throw an error condition to the front-end during
module loading and/or reading), this problem would not be this big.
We've had many similar issues with BibleTime where Sword API does not
(or rather is not able to) report module problems. Module issues have
lead to incorrect HTML being displayed to the user, causing the user to
believe something is wrong with the UI rather than the module.

Ideally, the Sword toolset should make it impossible to produce buggy
modules in the first place. Second, if a buggy or corrupt module is used
in a front-end, the end-user should be notified by the front-end if such
a case is detected by the back-end (for it is unreasonable for the
front-end code to include such detection logic).

Unfortunately this is not how Sword (or the Sword++ fork) works today,
but historically there are valid reasons for this. Needless to say, at
this point such changes to re-architecture and reimplement Sword would
require a lot of effort (even more if you want some kinds of
backwards-compatibility).


Yours,
J