|
Based on Peter's good advice and sound
reasoning, I'm appending an "eb" to every Bible module name in the
eBible.org repository. I didn't want to lengthen the module names
excessively with something like "eBible_org" or even "ebib" on the
end-- just enough to avoid collisions among less than a dozen
repositories. These module names get crammed into really small
spaces at times, for better or for worse, at least for display.
One letter appended didn't seem quite enough for clarity, but two
letters provides 676 possible combinations and a reasonable chance
of assigning sequences that make sense, like cw, ib, xi, etc. I'm
not putting in an obsoletes line in the conf files for these
changes, leaving a manual cleanup challenge behind. Such obsoletes
lines would have undesired side-effects in the case of existing
collisions, especially the worst kind, where names differ only by
case. I'm assuming that the other modules probably won't change
their module names for existing modules, being already fully
public and in general use already, but might adopt a similar
convention for all new modules.
I regret any inconvenience this naming convention change may cause for those awesome people who have been testing the eBible.org repositories. It seems that this little thing will solve more problems (including solving problems in advance) for more people than the inconvenience it may cause. In the case of the non-Bible modules on the eBible.org repository, I'm not renaming them at this time, because they are bit-for-bit copies of the same modules from Crosswire main. Therefore, duplication should not be a problem. Those are there merely as a convenience. They could be removed if they actually do cause a problem. Module abbreviations are mostly unchanged. Collisions could happen. I think the consensus is that those will be dealt with by the front ends when they happen for particular users. In other news, I have (1) disabled morphology tags that don't use the same system as DM's KJV, and (2) corrected a bug in the code where it was possible for Haiola to miss generating a GlobalOptionFilter=OSISMorph line in the conf file. The new grcTisheb module should at least display correctly, even though it is missing some features. I'll deal with that later. Maybe. Ideally, I will restore the missing features when I learn some things I don't yet know and have time to implement that. Thank you, front end developers, for making adjustments to handle another very large repository. Thank you, all who have tested the new repository and pointed out opportunities for improvement, some of which have been essential. With the addition of the new eBible.org repository:
Yesterday's conf clean-up is done, and moved to http://eBible.org/sword. The renaming process is in progress, module by module, at http://eBible.org/swordbeta. On 09/03/2015 04:05 AM, Peter von Kaehne wrote: On Thu, 2015-09-03 at 09:29 -0400, Karl Kleinpaste wrote:Adding complexity to configuration will not solve the problems being fought. Module de-dup and filesystem choice conflicts are readily solvable. Analogy: I'm finishing up a novel, and I need a title. Hm, how about "To Kill a Mockingbird"? Um, no, that's taken, and we expect written works (hm) to have unique titles. There is just one Romeo and Juliet, one Midsummer Night's Dream, and one The Tempest. Now apply the idea to Sword modules.Yes, but Romeo and Juliet is produced by a dozen of different publishers, because it is thankfully out of copyright.http://www.amazon.com/s/ref=nb_sb_ss_c_0_10?url=""> -alias%3Dstripbooks&field -keywords=romeo+and+juliet&sprefix=romeo+and+%2Caps%2C339 Most of these are by Shakespeare, some are some tribute plays or whatever by other authors. Amazon can handle this, my bookshelf can handle this, CrossWire should handle this.the eBible repository is currently nowhere advertised. People who*ahem* Nobody's getting off that easily. I alone had no less than 6 reports about eBible's failure to deliver content, all because Michael wasn't testing his own repo before repeatedly announcing "all is well!" to the world even when nothing was working. Others reported problems as well. So I'm not buying that. I don't expect us to have to deal with a repo that was effectively bricked without its owner even knowing it.Leaving aside Michael's initial start-up difficulties, it remains a fact that until eBible is part of the automatic repo updater, advertised on the Wiki and elsewhere it remains a beta or even experimental repo. People will need to live with breakage. And my proposal has the beauty that the only breakage some people will experience is that they will suddenly have 2 SpaRV2009 from eBible (one called SpaRV2009 and SpaRV2009ebib. Nothing will actually break.eBible repo has waited a long time to become available. I think another week or three ...I agree that we can wait a little while longer, but my proposal changes nothing to the negative, but removes in one fell swoop a whole range of options for damaging failure. Peter _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page --
Aloha,
|
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
