Bible Analyzer User's Forum

In the standard ASV module (the one without the Strong's numbers), Acts 18:7-28 is solid italic, from verse 7 to the end of the chapter.

In the ASV, the first italic word in that chapter occurs at verse 11, and it is one word only.
The problem is caused by a stray italic HTML tag at the end of verse 6. I have corrected it on my personal copy. I am unable to attach a corrected version here because the filesize is too large to attach. Do you want me to email the corrected "asv.bib" to you?

Kind regards,

There were actually 121 of these stray tags.

I uploaded a fixed update. Use the Download Manager to install.

Thanks.

Thanks for posting the update. I made a backup copy of the existing ASV module, and then reinstalled the ASV again. However, the Download Manager did not show that the ASV had been corrected. I would have expected a 2024 datestamp on the file, and maybe an augmented version number. See:
What exactly does the "v1.1" mean in the filename? (I know that "v" means version. I suppose that it means that something has been fixed, improved, or added to an earlier version of the same file, and that the version number should correspond to the file I want to download.)

In other words, when you issue a corrected version of an existing Module, can you adjust the date and version number for the Download Manager? Or is this impossible, because if you changed them, the Download Manager would think you are using a different Bible entirely?

Thanks again for the time and attention you take in this ministry. I appreciate you.

I removed the version info from the title and updated the date.

Usually, I put update notices in the module information page of a title.

How practical would it be for the "Module Download Manager" to alert you that there are newer versions available of the modules that you have downloaded? I can see this becoming complicated since we have the ability to create our own modules (which I appreciate) and even fix our own copy of the official download. That might make it difficult to decide if the official version on the download server is newer than the one on our hard drive. Editing our own copy would change the file date, making that means of determining which copy is more "updated" unreliable. I suppose embedding version or revision information in the module could be a monumental task because of all the modules that have been "deployed" will be on users' hard drives without version/revision information.

Perhaps I've just muddied the waters, but maybe this suggestion gives you food for thought...

Robert

Reply to:

How practical would it be for the "Module Download Manager" to alert you that there are newer versions available of the modules that you have downloaded? I can see this becoming complicated since we have the ability to create our own modules (which I appreciate) and even fix our own copy of the official download. That might make it difficult to decide if the official version on the download server is newer than the one on our hard drive. Editing our own copy would change the file date, making that means of determining which copy is more "updated" unreliable. I suppose embedding version or revision information in the module could be a monumental task because of all the modules that have been "deployed" will be on users' hard drives without version/revision information.

I am not terribly familiar with how the SQLite files are created for the Bibles, Dictionaries, Commentaries, and Graphics, but here is what I think might need to be done to accommodate user-created modules, user changes to existing BA modules, and how BA could update only official modules.

1. Create an additional table for BA-release data, which contains 3 rows

1.1. Row 1 is the release date

1.2. Row 2 is the release number

1.3. Row 3 is an SHA-256 hash of the contents of all the other tables, except the current table

2. If users create their own modules, it will not contain the BA release table, so the BA module updater will know that this table cannot be updated. However, for the first deployment of modules with the new table schema, this feature will be skipped and the title table will be used.

3. If users update an existing BA module to correct a spelling error or something, they will almost certainly not update Row 3, the hash, so the calculated hash of the other tables will not match the value of the hash in row 3, which indicates that this module has been changed from what it was when released. The module updater will compare the release number of the current module with the release number on the BA official site. If a newer release exists AND if the current module has been changed, the changed module will be renamed for a backup comparison and the newer module downloaded.

4. If an existing BA module is checked for update by comparing the version numbers, and the value of Row 3 matches the value of the calculated hash for that module, the user has made no changes, and the new module will be downloaded and overwrite the existing module. This will satisfy the overwhelming majority of cases.

What do you think?

It probably doesn't matter what I think since Tim will have to be the one to implement it if he sees fit, but here are my two cents...

Your scheme should probably work, although I suspect a new table wouldn't be necessary. In my opinion, the values you propose adding would make more sense as additional fields to the record in the "title" table since they would apply to the title. These fields would not be populated or exist (depending on how you wanted to handle it) in user-created modules.

There could be code in BA that could add these fields (or your table) to official modules or else their absence could trigger the download of the new update that contains these fields. This could be done at program start-up or when the "Module Download Manager" is run. The problem of doing this at program start-up is that it might delay the program's start-up too long, making the user think something is wrong. Doing it the first time when all the modules need to be updated may not be a problem, but if checking all the modules at every start-up takes too long, then that might not be practical.

If it takes too long to check all the modules at start-up, then the alternative would be when the Module Download Manager is run. Unfortunately, that may mean that you won't be notified that there an update is available until you think to run the Module Download Manager. It would be nice to be notified at program start-up that a module has an update, but not a deal-breaker if that's not practical. I'm sure checking the date/version info of each local module against the official date/version on a web server has some overhead. The Download Manager has that info when it shows the list of available modules, so that may be the most practical place to do all this.

I may be totally off-base with my thoughts since I don't know the implementation details of how Tim has things setup inside the Module Download Manager.

Robert

Thanks for the suggestions and ideas, but I do not foresee making more than peripheral changes to the Download Manager process.

Although building a system like this seems pretty intuitive, making any type of integrated download system is an involved process. It took me weeks to design Bible Analyzer's and if I was going to do it again I definitely would change some things, such as add a versioning system, but since Bible Analyzer modules are not updated very often, I doubt that I'll take the time to add that.

The Download Manager system is rather involved. When the Download Manager is started it checks for an internet connection and when found downloads a simple text-based data list of all the available titles and their specifics. This data is used to populate the Download Manager display. When the user enters their credentials, the data is sent via Python to an online PHP script that checks and parses the tables of the Store MySQL database. When an account is matched, all the necessary order data is parsed and returned via PHP and Python. This data is checked against the installed modules on the local system to determine which are present and/or loaded. Also, any purchased data is saved to the local system to mark which items are "Purchased."

When a title is marked for download and Download Button is clicked, the data is sent again to an online PHP script that uses a simple substitution scheme to access the compressed file for download. (The substitution is needed to keep the actual URL of the file from being exposed. Bots and humans could access a direct link otherwise). The file is downloaded via "chucks" and when complete thew Bible Analyzer code extracts and places the files in their proper locations. Then Bible Analyzer is automatically restarted to load the new titles and check them for all necessary tables (Some older titles lack tables that were added later), and then Bible Analyzer displays the new titles.

This has been a very brief overview. There are many unmentioned but necessary functions in between. Changing any of the core functions is problematic and I doubt I ever do, but adding a new add-on feature is not out of the question.

At present, the best way to check for new titles is simply sort the Download Manager list by date. If there is any doubt the newest file is installed, just download it again. Unless a user has modified a title, all should be well.

I am open to having a place on the forum where user created modules are made available, with any that may be beneficial potentially being added to the Download Manager.