On 09/01/2015 09:29 AM, DM Smith wrote: > Having Abbreviation=KJV for a Thai module is clearly not the intent. To use > it within a repo with uniqueness by language is entirely a bad idea. I'm glad I didn't misunderstand this aspect. > Collisions are bad. There is always some nook or cranny in the code that has > made some assumption about the [name]. The fundamental issue is whether use of Abbreviation is for uni- or bi-directional usage, that is, output only vs. input and output.
If Abbreviation is to be used as nothing but a display artifact, so as to show convenient, familiar, short names to users in headings and tabs and module lists and whatnot, then the problem is uni-directional and remains relatively simple. This is "output" usage alone. You can't make a mistake because nothing internal is ever looking at a module name as anything but the Real, and substitution is needed only at the last instant as code must scribble out the Abbrev instead. However, if Abbreviation is also a way for users and module authors to reference modules, then the problem is bi-directional, such that conflicts present themselves, and Abbreviation must become unique. I put bi-directional capability into Xiphos, so that it both finds Real->Abbrev for display purposes as well as considers Abbrev->Real substitution in places like bookmarks and module-internal references: If a bookmark says "KJV Gen.1.1," then Xiphos will see if there is an abbrev "KJV" to substitute before it navigates. If a module contains an internal reference link to "sword://Josephus//The+Antiquities+of+the+Jews/Book+1/Chapter+1/Section+4" or "sword://Jub//Jub/5/6" (and one of mine has lots of these), then Xiphos will determine whether "Josephus" or "Jub" is an abbrev before it decides how to navigate the genbook pane. This is "input" usage on top of "output" usage. Here's a fun implication: Xiphos speaks BibleSync Protocol <http://www.crosswire.org/wiki/BibleSync>. When Alice's Xiphos navigates in her real KJV, BSP shovels out a nav packet showing KJV, after being potentially substituted Real->Abbrev,because we in Crosswire app development should not expect other BSP-capable apps to understand our sometimes peculiar module names. Real KJV has no Abbreviation so it goes out as-is. Now, as Bob's Xiphos receives this, it is treated as a potential abbreviation. So Bob's Xiphos will do Abbrev->Real substitution on "KJV" to find "engKJV2006" and display that. Now going the other way, Bob navigates his engKJV2006, generating a BSP nav packet with Real->Abbrev substitution showing "KJV" which will be analyzed as a potential abbrev by Alice, which will drive her Xiphos wrongly to display engKJV2006 if she has it installed even though she expected that "KJV" actually means real KJV that she was already using. On the one hand, this is appropriate, given that this sort of usage is inherently both output from Alice and input to Bob in the 1st case, and vice versa in the 2nd...but on the other hand it is wrong in its effect due to non-uniqueness. I don't see how one can avoid a need for uniqueness if Abbreviation applies to input. > If there are ten KJVs in the list, how am I to know one from the other. FYI, in Xiphos' module list trees -- sidebar, module manager, advanced search, and parallel bible/commentary selector trees -- modules with abbreviations show up as "Abbrev (Real)" so that it is clear to the user what he's getting when he sees the selections. > (I do like Peter’s suggestion of allowing the end user to change/add an > Abbreviation for one or both. But it’ll be a while before all users upgrade > to a front-end that has such support.) I am in the middle of adding code to Xiphos that [a] ignores Abbreviation when it collides with an existing real module name, and [b] provides for the user to change Abbreviation at any time, which value is also retained across an update (like CipherKey is retained), so the user can de-collide as he wishes.
_______________________________________________ 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