|
On 09/03/2015 10:50 AM, Peter von
Kaehne wrote:
Oy! :-) Michael, we are still discussing and trying to find a consensus which will last! Please do not do anything just yet. Too late. Actually, if I need to undo what I just did, that can be done, but I don't think that is likely, even if we go with DM's idea. Putting a repository source in the datapath is actually a great idea, but still doesn't solve the conf file name collision problem by itself, nor does it solve the zip file name collision problem. We would still need some sort of name space appendage in the module name. And if we do that, we don't really need to change the data path per repository unless we want to for other reasons. If we were starting from scratch, we could do all sorts of things that make more sense and/or are cleaner and more elegant. The challenge comes with trying to find a solution that deals with the following current realities, which will probably be true for at least a year (and maybe forever in some front ends):
I think whatever we should do should be permanent and consensual I remain convinced that my proposal is the best as it will work immediately with all frontends of all kinds and requires no changes, but DM's suggestion has also advantages, including being a cleaner division for the long term. Where is Troy and what does he think? Peter On Thu, 2015-09-03 at 10:21 -1000, Kahunapule Michael Johnson wrote: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: More people will be able to use Sword project software for Bible study on their favorite devices and in their own language. Adding new Bibles and Bible portions to the Crosswire Sword module collection just got orders of magnitude easier and faster. Frequent revisions and additions for translations that are in progress are truly practical, now. New books can be added or updated as they are completed or revised. We have a way of easily tapping into Paratext projects for rapid updates, which is actually happening now with about a dozen projects. We have a way to quickly publish any Bible we get permission for from the Every Tribe Every Nation Digital Bible Library. This is a level of automation and service that I think is a great advance for the Crosswire Bible Society. Pat yourselves on the back, because I can't reach you from my computer. OK, now back to work. ;-) 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, Kahunapule Michael Johnson MICHAEL JOHNSON PO BOX 881143 PUKALANI HI 96788-1143 USA eBible.org MLJohnson.org Mobile: +1 808-333-6921 Skype: kahunapule _______________________________________________ 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_______________________________________________ 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
