bibledit-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [be] Bibledit Bloat


From: Jonathan Marsden
Subject: Re: [be] Bibledit Bloat
Date: Wed, 05 Aug 2009 10:42:33 -0700
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

Teus Benschop wrote:

The installation package of Bibledit gets bloated, but the program itself remain lean and fast. The bloat in the package is caused by
the addition of several resources to it. Recently it got a full KJV
Bible included, including Strong's markup, and today it got a full
USFM description (4 Mbyte) included as well, bringing the total
package size to now 11 Mbyte. It already has a lot of keyterms. And
soon more resources are going to be added to it, increasing the size
rapidly. What do you guys think of how to handle this? Thanks for
hints. Teus.

One approach is to package the extra data separately, so users can choose whether or not to install such additional items. This means that the base bibledit tarball would not include these "extras", and Bibledit must be able to run and work fine when they are not present.

For large documents such as KJV and the USFM description, would it be worth considering making these accessible within BE using the SWORD library -- this way, documents are added by installing SWORD modules, so a user who reads the KJV in BibleTime or Xiphos re-uses that same SWORD module inside Bibledit? This would also make the USFM description document readable in other SWORD-enabled software.

I realize there may be good reasons not to use SWORD in Bibledit, or a historical choice may have been made not to use it, but if things are now changing so BE wants access to multiple large documents, including bibles, perhaps it is time to look into using SWORD for that? Making the new resources which you refer to available as SWORD modules then (a) keeps Bibledit small and (b) makes the resources more widely available to others.

If SWORD is not a good fit, then some other systematic means of creating multiple separate data modules which BE can use seems like a good way to go. This would allow each user to decide which data modules they want to install and use, rather than force all BE users to download and install all of them.

Jonathan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]