<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/03/2015 10:50 AM, Peter von
Kaehne wrote:<br>
</div>
<blockquote cite="mid:1441313420.21007.16.camel@gmx.net" type="cite">
<pre wrap="">Oy! :-)
Michael, we are still discussing and trying to find a consensus which
will last! Please do not do anything just yet. </pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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):<br>
<ul>
<li>Module names need to be unique across repositories, such that
one module name refers to exactly one module (or at least <b>identical</b>
copies of the <b>same</b> module if it is in more than one
place).</li>
<li>Front ends tend to <b>truncate</b> the displayed module name
in some contexts, so the <b>most interesting </b>portions of
the module name need to come <b>first</b>.</li>
<li>With hundreds of languages represented, the language code is
probably the most significant part of avoiding module collisions
and finding the right Bible. Module name space is the least
interesting to the Bible student, but still necessary to prevent
collisions.<br>
</li>
<li>Module names have to be meaningful for human readers, or at
least not too obscure. (This rules out use of GUID strings, like
f365941f-598f-5332-8999-b52456c5f69a, which identifies my KJVD
in ePub format, but you can't tell just by looking.)</li>
<li>Module name has to match the name of the .zip file and (give
or take case) the directory containing the module files.</li>
<li>Any changes in the Sword Engine or front ends requires time to
roll out, even if we are quick to upload fixes. Not all front
ends have "push" upgrade mechanisms or even upgrade
notifications.<br>
</li>
</ul>
<br>
<br>
<blockquote cite="mid:1441313420.21007.16.camel@gmx.net" type="cite">
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="http://eBible.org/sword">http://eBible.org/sword</a>. The renaming process is in progress, module
by module, at <a class="moz-txt-link-freetext" href="http://eBible.org/swordbeta">http://eBible.org/swordbeta</a>.
On 09/03/2015 04:05 AM, Peter von Kaehne wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, 2015-09-03 at 09:29 -0400, Karl Kleinpaste wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Yes, but Romeo and Juliet is produced by a dozen of different
publishers, because it is thankfully out of copyright.
<a class="moz-txt-link-freetext" href="http://www.amazon.com/s/ref=nb_sb_ss_c_0_10?url=search">http://www.amazon.com/s/ref=nb_sb_ss_c_0_10?url=search</a>
-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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the eBible repository is currently nowhere advertised. People
who
</pre>
</blockquote>
<pre wrap="">*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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">eBible repo has waited a long time to become available. I think
another week or three ...
</pre>
</blockquote>
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<pre wrap="">
--
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: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<p><font color="#000000">Aloha,<br>
<i>Kahunapule Michael Johnson</i></font></p>
<table cellpadding="7" cellspacing="0">
<tbody>
<tr>
<td style="background: rgb(255, 255, 0)"><font
color="#000000"><b>MICHAEL JOHNSON<br>
PO BOX 881143<br>
PUKALANI HI 96788-1143</b><br>
USA</font></td>
<td style="background: rgb(0, 255, 255)"><font
color="#000000">
<a href="http://eBible.org">eBible.org</a><br>
<a href="http://MLJohnson.org">MLJohnson.org</a><br>
Mobile: +1 <b>808-333-6921</b><br>
Skype: kahunapule</font></td>
</tr>
</tbody>
</table>
</div>
</body>
</html>