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 there (and it would not solve the problem of legacy software). We _can_ afford to have make changes more attractive than not changing. I further think: Michael is clearly a patient soul, but what if we would be able to convince a major commercial publisher to go live with their stock as a repository? We would have the exact same scenario with a multitude of duplications but would we again be able to faff about with "this needs to be solved, that needs to be solved prior to you going live"? Most would walk away, very fast. People would think we never thought it through how to go big (well we never had, as eBible shows us, but now or never...) My proposal is simple and states to anyone who wants to join our fold : Yes, great, all very simple. Your module names need to be formed like this "SpaRV2009Zondervan", "SpaRV2007CrossWay". Nice and easy. We could then go into further slower and less urgent discussions re what may obsolete what across repos etc. Or not. There is the option to put the publisher ID prior to the remainder of the module name, but it would make even more of a mess in legacy applications without Abbreviation support. "ZondervanSpaRV2009" would become in David's example "Zonder..." just like "ZondervanKJV2008". There is finally the option to add the Publisher ID into the conf as a entry and have it added to the datapath, while leaving the ModuleName untouched. ModuleName=[SpaRV2009] Publisher=eBible DataPath=./modules/texts/ztext/sparv2009ebible This would eliminate crashing clashes dt indeces being not cleared, but it would not allow naming duplicates to co-exist until some changes are done to the software. It would also break our convention that ModuleName and datapath are identical in all but case. Peter On Thu, 2015-09-03 at 09:08 -0400, DM Smith wrote: > 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 repo clashing with another. I think this would take a > software change. > > JSword did this initially. It caused problems for people that had > more than one frontend as they could only see the “classic” sword > folder. So we changed it to a single shared download location. > > I think this is a better long term solution. > > In Him, > DM Smith > > > On Sep 3, 2015, at 5:26 AM, Peter von Kaehne <ref...@gmx.net> > > wrote: > > > > 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 fixed > > > > And right now we (i.e. mostly Michael) get(s) bogged down on (2) > > while > > (1) is what we/he really should concentrate upon. > > > > Recent emails re duplications (I started it, so I tap my nose) are > > a > > case in point. If we could ensure that no module of Michael is ever > > installed on top of a module from us (in the widest sense - IBT, > > Xiphos, CrossWire, NET) then things would be a lot smoother > > already. > > Yes we might have a multitude of modules in triplicate, but that is > > then a minor inconvenience which can be sorted at leisure instead > > of > > delaying the start up of the repo. Given that we have 1000s of > > modules > > between us, it is likely that we will find showstopping > > duplications > > for some time to come - unless we do something drastic: > > > > Proposal: > > > > 1) Add a namespace element to ModuleName and datapath. Initially we > > do > > this solely for eBible, but we can then expand that to other > > repos/publishers. This removes all risk of duplication upon > > existing > > installs - yes the user will then have two KJVs or whatever, but no > > corruption of indeces, or mess of his private notes. So Michael's > > texts > > should all have a Modulename like SpaRV2009ebib and a data path > > sparv2009ebib. > > > > 2) Enact some discipline prior to posting > > a) - no new non-showstopping threads on ebible until we got the > > repo > > online. > > b) - thread discipline. I am very interested to see eBible > > happening, > > but I find it hard to follow the multitude of threads. > > c) - bugs in frontends are bugs in frontends and not eBible's > > problems, > > even if triggered by eBible. > > > > Thanks > > > > _______________________________________________ > > 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 _______________________________________________ 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
