Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On 09/03/2015 07:09 PM, Kahunapule Michael Johnson wrote: > Please make sure you get a fresh copy from the repository. I always refresh immediately before such tests; such was the case 90 seconds before I wrote. > the morphology tags have been stripped from this module for now. Those > may come

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On 09/03/2015 10:50 PM, Peter von Kaehne wrote: > > Where is Troy and what does he think? I have just arrived back from being tour-guide for my sister on vacation and now I need a vacation :) I've been following these threads, catching up when I have time, and I think the conversations

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

Welcome back, Troy. Enjoy the vacation from your vacation.  ; The "eb" namespace trailer has now been added to all of the Bible modules in the eBible.org repository. The last update cycle is complete, and the repository is at rest. eBible.org

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

See below: On 09/04/2015 01:43 AM, Karl Kleinpaste wrote: On 09/03/2015 07:09 PM, Kahunapule Michael Johnson wrote: Please make sure you get a fresh copy from the repository. I always refresh

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

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

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On 09/03/2015 09:54 AM, Greg Hellings wrote: > It would necessitate changes to existing front-ends, but they would not be > drastic. Generally speaking, I am suspicious of things that require "changes to [all] existing front-ends," because then it smells very much like something that ought to be

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

This is a proposal I've brought up multiple times in the past when people have said it would be difficult to resolve multiple copies with the same name. It would necessitate changes to existing front-ends, but they would not be drastic. However, this only addresses the duplication issue in terms

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

Yes, it requires no change to existing software. Yes, it makes the move towards Abbreviation more compelling, but does not actually require it. And I think these both "yes" are a necessity right now. We can not afford to do any _required_ changes as it would take forever before all frontends are

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On Thu, 2015-09-03 at 08:54 -0500, Greg Hellings wrote: > This is a proposal I've brought up multiple times in the past ... > On Thu, Sep 3, 2015 at 8:08 AM, DM Smith > wrote: > > If we had each repository downloaded to its own folder, > > > > > On Sep 3, 2015, at 5:26

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

In terms of precendent: the Wycliffe repo uses namespaces in modulenames. Per copyright owner rather than repo publisher, but still. [lang]_[namespace]_[year] is the form of modulenames there. For reasons David has mentioned - small displays, this is not ideal. [lang]{year](namespace] or

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

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

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On Thu, 2015-09-03 at 14:32 -0400, DM Smith wrote: > If I’m right then one could rename the kjv.conf to whatever-kjv.conf > and it would work just as well. > > If this is the case, then the conf can have a namespace prefix. yes, that will work. At least for Sword. I have not tested JSword on

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On 09/03/2015 04:21 PM, Kahunapule Michael Johnson wrote: > The new grcTisheb module should at least display correctly, even > though it is missing some features. - grcTischeb.conf is not individually in eBible's pub/sword/mods.d, though it is present within pub/sword/mods.d.tar.gz. -

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

Oy! :-) Michael, we are still discussing and trying to find a consensus which will last! Please do not do anything just yet. 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

[sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

Dear all, Looking at the flurry of emails from the last few weeks I am thinking if I was Michael, I would start hitting my head against the wall. There are quite clearly two kinds of problems: 1) Things that stop us actually putting the repo formally online 2) Things that would be nice to get

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

Peter, I'm a bit reluctant to see even longer module names than what we have already, though I can appreciate that including a namespace might somehow solve the collisions problems. cf. Long module names such as SpaRV2009ebib could be a problem for some mobile apps with small screens, unless

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On 09/03/2015 12:02 PM, Karl Kleinpaste wrote: On 09/03/2015 04:21 PM, Kahunapule Michael Johnson wrote: The new grcTisheb module should at least display correctly, even though it is missing some features. -

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

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,

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On 09/03/2015 05:26 AM, Peter von Kaehne wrote: > Looking at the flurry of emails from the last few weeks I am thinking > if I was Michael, I would start hitting my head against the wall. I'm not Michael, and I already feel like I've been beating my head against eBible's wall. In an

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

BTW, I'm thinking about adding a snippet of code to Xiphos' mod.mgr to check to-be-installed modules' DataPath against all installed modules, to ensure that no conflicts are manufactured. Seems to be reasonable self-defense against poor choices. ___

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

On Thu, 2015-09-03 at 03:55 -0700, David Haslam wrote: > cf. Long module names such as SpaRV2009ebib could be a problem for > some mobile apps with small screens, unless perhaps the front-end > makes better use of Abbreviation. The eBible repo represents such a big amount of new modules that

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

This suggestion requires no change to existing software. It almost necessitates software to be changed to use Abbreviation and to do that well. If we had each repository downloaded to its own folder, e.g. ebible, xiphos, ibt, sword, sword-beta, … that would solve the mechanical problem of one

Re: [sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

Peter is right. Looking toward the bigger and brighter future, the module name should be an internal code to represent a particular text from a particular publisher. By "publisher" I mean whoever actually created the module, not the copyright holder. If another publisher wants to issue the