<div dir="ltr"><div>Jaak,</div><div><br></div><div>I'm not sure why you choose this hill to die on when BibleTime already does exactly this for the module info.</div><div><br></div><div><a href="https://github.com/bibletime/bibletime/blob/a1c5848cf70d79f97b4a80c769b4d688b0b9560e/src/backend/drivers/cswordmoduleinfo.cpp#L1035-L1041">https://github.com/bibletime/bibletime/blob/a1c5848cf70d79f97b4a80c769b4d688b0b9560e/src/backend/drivers/cswordmoduleinfo.cpp#L1035-L1041</a></div><div><br></div><div>Why now, when it's UnlockInfo, does this suddenly become a problem?</div><div><br></div><div>--Greg<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 7, 2020 at 2:58 AM Jaak Ristioja <<a href="mailto:jaak@ristioja.ee">jaak@ristioja.ee</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> and you are refusing to do this because... it somehow doesn't have a<br>
> clear definition of what we are doing under the covers in our RTFHTML<br>
> filter.<br>
><br>
> Have I restated the exact current problem?<br>
<br>
No. The RTFHTML code does not properly handle corner cases leading the<br>
way to potential (security?) issues for our users, which is why we're<br>
not going to use that as it is right now. We at BibleTime have the<br>
capability to write a better parser, to do so we would need a spec. That<br>
spec would define the allowed syntax for module writers, hence it is a<br>
public interface and not a description of what RTFHTML does internally.<br>
This would be the specification for the protocol of how SWORD (created<br>
by Crosswire) interfaces with modules (created by module writers not<br>
necessarily from Crosswire).<br>
<br>
Actually, perhaps it were better if there was a spec about the output of<br>
RTFHTML, e.g. something like Gary suggested. This together with RTFHTML<br>
working properly (not crash, not have security bugs, properly report<br>
errors including due to incorrect input) will likely suffice for the<br>
needs of BibleTime at least for the foreseeable 5-7 years.<br>
<br>
A well-defined spec for the contents of that field (the input to<br>
RTFHTML) might still be needed for module writers / generators /<br>
converters etc to properly interface with SWORD. Note also that if your<br>
configuration files would be properly versioned (e.g. configuration file<br>
contains the version of the spec it conforms to), you would have no<br>
problems adding new features to the spec and to RTFHTML while also<br>
bumping the versions. If done properly, the engine could seamlessly<br>
handle module configurations conforming to different versions of the<br>
spec. For example, if your current spec is version 5, and you want to<br>
support a new feature in the configuration file, you just add the<br>
feature into spec version 6, and then amend the configuration files<br>
accordingly, e.g.<br>
<br>
[General]<br>
SwordConfigurationApiVersionRequired=6<br>
<br>
Unfortunately, since such versioning is not part of the current spec,<br>
you need certain workarounds for something like this to work for<br>
features which extend the INI-like syntax of the configuration file, not<br>
just what changes the semantics for the values or similar.<br>
<br>
There are also other possibilities to add new features in backwards<br>
compatible manner as well (so that module configurations with new<br>
features still continue to work with (some) older versions of Sword) but<br>
this is much harder to do properly (even without specs).<br>
<br>
Therefore, since adding new features can mostly be done properly with<br>
formal (versioned) specifications and mostly in compatible manner,<br>
citing something like this as an excuse to not having specifications is<br>
rather lame.<br>
<br>
What I am offering would not hinder SWORD from offering to frontend<br>
developers what you called "new modules and new functionality with new<br>
engine releases without any change in their code". On the contrary, I<br>
believe this would actually improve compatibility. Furthermore, I feel<br>
quite safe to state that proper specifications per se would not hinder<br>
you to continue to provide new features as you've done previously<br>
(except of course if you have already done certain things wrong). The<br>
biggest downside is that you have to properly update the spec as well,<br>
which might be tedious for people with not much experience in doing so.<br>
<br>
Whether this aligns with what you called your "purposes for the engine"<br>
depends on you, or so it seems. As things stand now for BibleTime we<br>
still have planned for BibleTime to use Sword++ instead of SWORD when<br>
the time is right.<br>
<br>
J<br>
<br>
<br>
On 07.01.20 02:06, Troy A. Griffitts wrote:<br>
> So, just to summarize for all who are reading this thread...<br>
> <br>
> o A new useful feature for the end user has been added to SWORD and<br>
> we're asking you to make this available to your user:<br>
> <br>
> to show them how to obtain an unlock key when they try to install<br>
> a locked module.<br>
> <br>
> The recommended way SWORD has for you to get the HTML for this is to use<br>
> these 2 lines:<br>
> <br>
> SWBuf unlockInfo = book->getConfigEntry("UnlockInfo");<br>
> RTFHTML().processText(unlockInfo);<br>
> <br>
> and you are refusing to do this because... it somehow doesn't have a<br>
> clear definition of what we are doing under the covers in our RTFHTML<br>
> filter.<br>
> <br>
> Have I restated the exact current problem?<br>
> <br>
> <br>
> To repeat. I don't WANT a concrete definition of what we are doing<br>
> under the covers. I WANT to be able to... for example... support some<br>
> new HTML or RTF tag we might need in the future and I will add that<br>
> support to the RTFHTML filter. All frontends using the recommended<br>
> lines above will magically get the new functionality without needing to<br>
> change or even know we support new tags under the covers. This is<br>
> intentional. SWORD is not a specification for someone to re-write. It<br>
> is an ever-growing library for programmers to use. We do our best to<br>
> keep our public interfaces backward compatible and try to make<br>
> improvements within the implementation.<br>
> <br>
> I am pushing back on your suggestion for the practical reasons:<br>
> <br>
> a) you can do what you need right now in a very easy way: 2 lines of<br>
> code-- which has been the way to do this for 20+ years.<br>
> <br>
> b) your suggestion to define a formal spec for what I am doing in the<br>
> RTFHTML filter will prohibit me from doing exactly what SWORD offers to<br>
> frontend developers: new modules and new functionality with new engine<br>
> releases without any change in their code.<br>
> <br>
> You are preventing your users from having functionality because we don't<br>
> do things the way you want. That's your choice. We offer the<br>
> capability. You won't use it for some esoteric reason.<br>
> <br>
> I am happy to cooperate, but not at the expense of our purposes for the<br>
> engine.<br>
> <br>
> Troy<br>
> <br>
> <br>
> <br>
> On 1/6/20 3:46 PM, Jaak Ristioja wrote:<br>
>> Dear Troy,<br>
>><br>
>> I think the bottom line is that you just don't care for our concerns.<br>
>> Because by the end of the day, after much labor to communicate and<br>
>> improve things, we are left empty-handed, and the concerns remain.<br>
>><br>
>> Yes, you have a bunch of justifications for why our concerns, proposals<br>
>> and patches are stupid, unimportant or irrelevant pseudo-problems. I'm<br>
>> sorry, but we disagree. However stupid our concerns might seem to you,<br>
>> this doesn't change the fact that we still feel otherwise: that our<br>
>> concerns are real.<br>
>><br>
>> Issue after issue, e-mail after e-mail our needs have been ignored and I<br>
>> feel that every such response from you just makes me more and more sick.<br>
>> It doesn't even matter if you know best, whether you're right or what<br>
>> your reasons are — deeds speak louder than words. The fact is that you<br>
>> have been very uncooperative and I feel that this has been quite toxic.<br>
>><br>
>> BibleTime will display the UnlockInfo in verbatim plain text only and<br>
>> will not attempt to parse any specific formatting syntax until a good<br>
>> enough (for me) formal specification for that syntax has been created.<br>
>> My offer to help specify the syntax formally still stands.<br>
>><br>
>> J<br>
>><br>
>> On 06.01.20 00:47, Troy A. Griffitts wrote:<br>
>>> Again, I would state that the problem you are having is that you aren't<br>
>>> content to use the SWORD engine as-is, but feel you need to redesign all<br>
>>> of its interfaces and re-implement large parts of the engine. I am a<br>
>>> consumer of the engine. I write frontends regularly against the<br>
>>> engine. If you would be content to simply use the engine as it is<br>
>>> written, you could write a frontend very quickly and without much effort.<br>
>>><br>
>>> I have often asked the bottom line question when you complain about<br>
>>> these things:<br>
>>><br>
>>> What exactly and practically, can't you do that you feel you need to<br>
>>> "hack around" the engine. What exact feature are you trying to<br>
>>> implement that all other frontend developers haven't implemented? We<br>
>>> eat our own cooking. We write many different frontends in many<br>
>>> different programming languages for many different sytles of Bible<br>
>>> research, and improve the engine as we find difficulties writing these<br>
>>> frontends. It is not as if we live in a bubble and don't actually use<br>
>>> our code. If 3 of my frontends all had the same hack because SWORD did<br>
>>> something unnecessarily odd, I would be the first one to push an update<br>
>>> into the engine. So, without specific examples of what exactly you are<br>
>>> having trouble delivering to your users because of large issues with<br>
>>> SWORD-- more specific than "hacks all over", we can't help you either<br>
>>> understand how we intend for you to use SWORD to deliver that<br>
>>> functionality and help you have an easier time, or else really see some<br>
>>> novel feature you are attempting to add which SWORD really doesn't<br>
>>> easily handle and find together a way to improve things. SWORD does<br>
>>> very specific tasks, each in a very specific way. If you use it as it<br>
>>> was intended instead of trying to change its programmatic paradigm to<br>
>>> what you think it should be, it works reasonably well and provides a<br>
>>> huge amount of services necessary for building a Bible research tool and<br>
>>> will isolate you from a ton of tasks common to many Bible research<br>
>>> tools, to let you focus on your users and your specific frontend, and<br>
>>> we'll try to protect you from having to rewrite your working code by<br>
>>> providing new modules and new features under the covers which you can<br>
>>> slowly add to your frontend if you feel it fits. If you "kick against<br>
>>> the goads" and try to make SWORD work in a way it wasn't intended, you<br>
>>> will likely run into issues. You have your entire frontend to design as<br>
>>> you see fit and use whatever programming paradigm you'd like. Simply<br>
>>> use SWORD as you would libz or libcurl or whatever other utility you<br>
>>> need. Accept their paradigm. If necessary, work within their paradigm<br>
>>> to add any features you see lacking, and save your idealism for your own<br>
>>> code. Life is too short to make everyone do things the way you think<br>
>>> they should do things.<br>
>>><br>
>>> Again, I want to improve the engine. If you are building X super cool<br>
>>> feature and really can't figure out a way to add your super cool feature<br>
>>> because SWORD doesn't allow it, I am happy to discuss how we can improve<br>
>>> the engine to give you and all other frontend developers the ability to<br>
>>> deliver X to our end users. But these conversations between you and I<br>
>>> are usually about incomplete specifications and lack of use of the<br>
>>> latest C++ features or the latest in vogue programming models or trying<br>
>>> to solve some theoretical problem no one has run into in 30 years of SWORD.<br>
>>><br>
>>> So, yes, I am not interested in changing a highly optimized and highly<br>
>>> portable codeset, to risk giving up that portability and optmization so<br>
>>> we can use the latest template library, latest programming paradigm, or<br>
>>> latest features in C++. Again, if you have a new feature you are<br>
>>> attempting to add to Bibletime and just can't do it because you have so<br>
>>> much trouble getting the data you need from SWORD, please let me know<br>
>>> and I would love to discuss and improve the engine for you and everyone<br>
>>> else.<br>
>>><br>
>>> Troy<br>
>>><br>
>>><br>
>>> On 1/5/20 2:35 PM, Jaak Ristioja wrote:<br>
>>>> Dear Peter,<br>
>>>><br>
>>>> I really wish it were as simple as adding amending a few vague<br>
>>>> statements. But actually, the specification is just plain incorrect in<br>
>>>> many ways not so easily amendable.<br>
>>>><br>
>>>> For example, the tutorial states that "whitespace can be around the = as<br>
>>>> well." and also gives an example: "ModDrv = zText". This is<br>
>>>> incorrect at least in part, because in such cases, SWConfig parses the<br>
>>>> key as "ModDrv " (with including the whitespace).<br>
>>>><br>
>>>> For another example, there are issues with the so-called "continuation<br>
>>>> lines". Whereas <a href="http://wiki.crosswire.org/DevTools:conf_Files" rel="noreferrer" target="_blank">http://wiki.crosswire.org/DevTools:conf_Files</a> states<br>
>>>> these are allowed in some places and not in others, it seems to me that<br>
>>>> continuation lines are allowed and work everywhere (as that logic seems<br>
>>>> to be incorporated into FileMgr::getLine() which SWConfig uses to read<br>
>>>> lines). Additionally, the tutorial states that under the "Continuation"<br>
>>>> section the following:<br>
>>>><br>
>>>> This is not a mechanism to make long lines more readable<br>
>>>> in the module.conf file. It is a means to introducing a<br>
>>>> break in the rendered output of that field when viewed by<br>
>>>> a front-end or installer. It is akin to a xHTML <br/>.<br>
>>>> That is, continuation is a formatting feature.<br>
>>>><br>
>>>> Please correct me, but it seems exactly the opposite, because the<br>
>>>> backslashes are stripped by FileMgr::getLine() so nothing can turn them<br>
>>>> into line breaks later. Continuation lines are simply a feature to make<br>
>>>> module.conf files more readable.<br>
>>>><br>
>>>> There are also several other issues, but its not the issues themselves<br>
>>>> that are holding me back. I think the greater obstacle is that in<br>
>>>> reality requires talks, exchange of information and much cooperation<br>
>>>> with Sword developers, including them fixing and improving the engine.<br>
>>>> But Sword developers are not that interested (see Troy's email dated<br>
>>>> Sun, 5 Jan 2020 13:23:40 -0700), they don't see such issues as big<br>
>>>> problems. And in the end frontend developers like us have to grind our<br>
>>>> teeth while hacking around their technically "wonderful" library.<br>
>>>><br>
>>>> As long as Sword developers continue to ignore most of our technical<br>
>>>> concerns, I don't see how me amending the wiki could be a solution. The<br>
>>>> best I could do is to document the brokenness. I don't see how it were<br>
>>>> possible for me to do better without more cooperation from the Sword<br>
>>>> developers, but it seems that once again we will not getting any of<br>
>>>> that... ;-\<br>
>>>><br>
>>>> J<br>
>>>><br>
>>>><br>
>>>> On 05.01.20 15:54, <a href="mailto:refdoc@gmx.net" target="_blank">refdoc@gmx.net</a> wrote:<br>
>>>>> Dear Jaak,<br>
>>>>><br>
>>>>> Thanks for the apology, accepted.<br>
>>>>><br>
>>>>> Wrt the further remarks, this is an open source project and a wiki. It is open <br>
>>>>> to change and improvements. In particular the Wiki is very open to improvements, <br>
>>>>> get yourself an.account and add where things are vague or unclear.<br>
>>>>><br>
>>>>> I agree in that module security can become an issue when powerful display <br>
>>>>> engines are used uncritically and without sufficient sandboxing and sanitizing <br>
>>>>> of module content. We try and safeguard by having our own upload criteria for <br>
>>>>> modules and only allowing repos to become part of the "official" set up which <br>
>>>>> guarantee a certain level of sanity. Security as a process.... But this may well <br>
>>>>> not be sufficient and in in the end each step of the process does benefit from <br>
>>>>> review and improvement at all times. So, join the wiki and improve upon it, feel <br>
>>>>> free.<br>
>>>>><br>
>>>>> As such (not speaking about RTF as I know least about that) much of the module <br>
>>>>> related engine output is subject to a sanity check within the filters whereby <br>
>>>>> unrecognised codes are nuked or made safe.<br>
>>>>><br>
>>>>> Peter<br>
>>>>><br>
>>>>> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.<br>
>>>>><br>
>>>>><br>
>>>>> -------- Original Message --------<br>
>>>>> Subject: Re: [bt-devel] NASB Unlock Key<br>
>>>>> From: Jaak Ristioja<br>
>>>>> To: <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> CC:<br>
>>>>><br>
>>>>><br>
>>>>> Hello Peter,<br>
>>>>><br>
>>>>> I apologize for my poor understanding. I misunderstood Troys reply to<br>
>>>>> mean that the wiki contains "the specification" and thought that he<br>
>>>>> meant the <a href="http://wiki.crosswire.org/DevTools:conf_Files" rel="noreferrer" target="_blank">http://wiki.crosswire.org/DevTools:conf_Files</a> page. Now that<br>
>>>>> you also mentioned <a href="http://wiki.crosswire.org/Tutorial:Writing_Conf_files" rel="noreferrer" target="_blank">http://wiki.crosswire.org/Tutorial:Writing_Conf_files</a><br>
>>>>> I see that this page actually contains most of the information I was<br>
>>>>> missing.<br>
>>>>><br>
>>>>> Thank you!<br>
>>>>><br>
>>>>> I also apologize if I've created a misunderstanding, e.g. by not being<br>
>>>>> thoughtful enough to formulate more clearly what I'm looking for as a<br>
>>>>> reference. You are correct that much of the information is available on<br>
>>>>> the two wiki pages, but I think these do not well add up to constitute a<br>
>>>>> single document which could comfortably be categorized as a formal<br>
>>>>> technical specification, because many of the details are described in an<br>
>>>>> informal and non-technical manner.<br>
>>>>><br>
>>>>> But then again I might still be wrong and in need of your corrective<br>
>>>>> remarks.<br>
>>>>><br>
>>>>><br>
>>>>> J<br>
>>>>><br>
>>>>><br>
>>>>> On 05.01.20 13:42, <a href="mailto:refdoc@gmx.net" target="_blank">refdoc@gmx.net</a> wrote:<br>
>>>>> > The subset of RTF and the encoding directions are for the last decade at<br>
>>>>> least<br>
>>>>> > in our wiki<br>
>>>>> ><br>
>>>>> > <a href="http://wiki.crosswire.org/Tutorial:Writing_Conf_files" rel="noreferrer" target="_blank">http://wiki.crosswire.org/Tutorial:Writing_Conf_files</a><br>
>>>>> ><br>
>>>>> > I do not mind intelligent criticism of the wiki, but declarations of<br>
>>>>> absence of<br>
>>>>> > information by long standing collaborators should be verified by running a<br>
>>>>> > simple search if the information is not found on first glance<br>
>>>>> ><br>
>>>>> > Jaak, that is directed at you.<br>
>>>>> ><br>
>>>>> > FWIW, this info on this page has been lifted (by David or me) from the<br>
>>>>> original<br>
>>>>> > static tutorial subside, so is there for about 20 years in one form or<br>
>>>>> another.<br>
>>>>> ><br>
>>>>> > Peter<br>
>>>>> ><br>
>>>>> > Sent from my mobile. Please forgive shortness, typos and weird autocorrects.<br>
>>>>> ><br>
>>>>> ><br>
>>>>> > -------- Original Message --------<br>
>>>>> > Subject: Re: [bt-devel] NASB Unlock Key<br>
>>>>> > From: Jaak Ristioja<br>
>>>>> > To: <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > CC:<br>
>>>>> ><br>
>>>>> ><br>
>>>>> > It helps a bit, but that is a very loose definition, and hence ambigious.<br>
>>>>> ><br>
>>>>> > For example, starting with RTF: which version of RTF? The latest version<br>
>>>>> > (1.9.1) of the RTF specification is 278 pages long, dated 19 March 2008.<br>
>>>>> > The whole of it (including support for style sheets, tables, lists,<br>
>>>>> > indenting, hyperlinks, line spacing, paging, margins, embedded fonts,<br>
>>>>> > drawing objects, pictures, UTF-16, unicode escapes, codepages, character<br>
>>>>> > sets, embedded OLE objects, bi-directional text, ruby, ...) or only only<br>
>>>>> > a subset? Which subset? Probably limited to ? Can the parser<br>
>>>>> > expect the representation format to be ASCII (with escapes) according to<br>
>>>>> > the RTF spec?<br>
>>>>> ><br>
>>>>> > Now, adding links to the mix, should this HTML construct<br>
>>>>> > be parsed inside all RTF constructs or just certain contexts? Or should<br>
>>>>> > the HTML element be parsed before RTF? Can the display text<br>
>>>>> > inside the tags also contain RTF?<br>
>>>>> ><br>
>>>>> > From the perspective of writing a valid parser for these configuration<br>
>>>>> > entries, such details matter a great deal, which is why I'm concerned.<br>
>>>>> ><br>
>>>>> > Even with plain text entries, I couldn't find information about whether<br>
>>>>> > these are encded in ASCII, UTF-8, ISO-8859-?? or something else. In case<br>
>>>>> > its UTF-8, is the byte-order mark allowed at the beginning of the<br>
>>>>> > configuration file?<br>
>>>>> ><br>
>>>>> > I apologize if this sounded picky, but such details really do matter<br>
>>>>> > from the perspective of writing correct and safe parsers. And you might<br>
>>>>> > not agree with me, but I find it very important that our users get<br>
>>>>> > high-quality software not just in terms of features, but also in terms<br>
>>>>> > of robustness, reliability and cybersecurity.<br>
>>>>> ><br>
>>>>> > With these things in mind and given the many bugs I've found when<br>
>>>>> > working on that code for Sword++, I must say I don't feel safe using<br>
>>>>> > Sword filters.<br>
>>>>> ><br>
>>>>> > But if I interpret your reply correctly, you suggest running the<br>
>>>>> > configuration value through the RTFHTML filter and use that as HTML?<br>
>>>>> > That at least gives me some clues about how you imagine it to work,<br>
>>>>> > which subset of RTF should be supported etc, but I'd prefer such<br>
>>>>> > information to be in the specification instead.<br>
>>>>> ><br>
>>>>> > I'd be glad to help improve these specifications, but this would entail<br>
>>>>> > quite a lot of scrutiny, very likely on the Sword code as well. Given<br>
>>>>> > that there has been some tension between us in the past, this might<br>
>>>>> > perhaps require a bit of forethought. :)<br>
>>>>> ><br>
>>>>> > J<br>
>>>>> ><br>
>>>>> ><br>
>>>>> > PS: The latest version (1.9.1) of the RTF specification is 278 pages<br>
>>>>> > long, dated 19 March 2008.<br>
>>>>> ><br>
>>>>> > PPS: You might want to cherry-pick this Sword++ commit into Sword to fix<br>
>>>>> > two HTML injection issues in RTFHTML:<br>
>>>>> ><br>
>>>>> ><br>
>>>>> <a href="https://github.com/swordxx/swordxx/commit/5959759d6951462f154dec663ea1805090a576bd" rel="noreferrer" target="_blank">https://github.com/swordxx/swordxx/commit/5959759d6951462f154dec663ea1805090a576bd</a><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> > On 05.01.20 02:15, Troy A. Griffitts wrote:<br>
>>>>> > > Hi Jaak,<br>
>>>>> > > What makes you think the specification isn't defined? It has always been,<br>
>>>>> > as many of our fields in the .conf file, RTF + a href links. If the wiki<br>
>>>>> > doesn't say this, it should. The RTF to HTML filter in the engine will give<br>
>>>>> > you content you can display in your html view.<br>
>>>>> > ><br>
>>>>> > > Hope this helps,<br>
>>>>> > ><br>
>>>>> > > Troy<br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > > On January 4, 2020 5:06:50 PM MST, Jaak Ristioja wrote:<br>
>>>>> > >> Hello Troy,<br>
>>>>> > >><br>
>>>>> > >> I guess we can display the UnlockInfo .conf entry as verbatim plain<br>
>>>>> > >> text. If support for hyperlinks and such would be needed, I would<br>
>>>>> > >> strongly prefer the format to have a formal specification which were<br>
>>>>> > >> acceptable to use in BibleTime.<br>
>>>>> > >><br>
>>>>> > >> The specification being "just some simple HTML" is not good enough,<br>
>>>>> > >> because passing the contents of such fields directly to some HTML or<br>
>>>>> > >> web<br>
>>>>> > >> view widget is not acceptable, neither is embedding it verbatim inside<br>
>>>>> > >> other HTML, because that might break our GUI layouts/HTML and comes<br>
>>>>> > >> with<br>
>>>>> > >> security concerns (we don't want modules to be able to crash BibleTime,<br>
>>>>> > >> run scripts, consume too much resources etc).<br>
>>>>> > >><br>
>>>>> > >> If you want I can help write formal grammars (EBNF or similar) for such<br>
>>>>> > >> things, as well as parsers, linters etc.<br>
>>>>> > >><br>
>>>>> > >><br>
>>>>> > >> Best regards,<br>
>>>>> > >> J<br>
>>>>> > >><br>
>>>>> > >><br>
>>>>> > >> On 05.01.20 00:56, Troy A. Griffitts wrote:<br>
>>>>> > >>> Hi Gary,<br>
>>>>> > >>><br>
>>>>> > >>> Thanks for the suggestion. We had to weigh the pros and cons of<br>
>>>>> > >> this.<br>
>>>>> > >>> Lockman is testing the module in a few of our applications and also<br>
>>>>> > >>> wanted to review the installation and unlock process. We decided to<br>
>>>>> > >> do<br>
>>>>> > >>> all we can to make it as easy as possible for their executives-- who<br>
>>>>> > >> are<br>
>>>>> > >>> not programmers-- to review and make a decision on permission.<br>
>>>>> > >>><br>
>>>>> > >>> One thing which has been mentioned a few times on sword-devel is that<br>
>>>>> > >>> frontends should begin to honor the new "UnlockInfo" .conf entry,<br>
>>>>> > >> which<br>
>>>>> > >>> has the purpose to explain to the user how to obtain an unlock key<br>
>>>>> > >> for a<br>
>>>>> > >>> particular module and in this modules clarifies to the user that this<br>
>>>>> > >>> module is still in the testing phase. It would be good to check<br>
>>>>> > >>> Bibletime to see if it has support for displaying "UnlockInfo" to the<br>
>>>>> > >>> user when a module is selected for installation.<br>
>>>>> > >>><br>
>>>>> > >>> Thanks again for all you guys do,<br>
>>>>> > >>><br>
>>>>> > >>> Troy<br>
>>>>> > >>><br>
>>>>> > >>><br>
>>>>> > >>> On 1/4/20 3:43 PM, Gary Holmlund wrote:<br>
>>>>> > >>>> Troy,<br>
>>>>> > >>>><br>
>>>>> > >>>> Thanks for the information. Perhaps Lockman should not be in<br>
>>>>> > >>>><br>
>>>>> > >>>> the masterRepoList.conf until it is available for purchase.<br>
>>>>> > >>>><br>
>>>>> > >>>> Gary<br>
>>>>> > >>>><br>
>>>>> > >>>><br>
>>>>> > >>>> On 1/4/20 11:12 AM, Troy A. Griffitts wrote:<br>
>>>>> > >>>>> Hey guys. We don't have a deal with Lockman yet. They are<br>
>>>>> > >> reviewing<br>
>>>>> > >>>>> the latest work we've done and have pointed out a few issues we are<br>
>>>>> > >>>>> trying to fix. It does seem like we are at the brink of actually<br>
>>>>> > >> having<br>
>>>>> > >>>>> the NASB available, but we've said this for years, so I don't want<br>
>>>>> > >> to<br>
>>>>> > >>>>> promise anything. There is no place to purchase an unlock key yet<br>
>>>>> > >> and<br>
>>>>> > >>>>> when there is, it will be directly from Lockman. SWORD has had<br>
>>>>> > >> single<br>
>>>>> > >>>>> unlock code functionality unchanged for years in the engine. If<br>
>>>>> > >> Lockman<br>
>>>>> > >>>>> decides they want unique unlock codes per user, then you will need<br>
>>>>> > >> to<br>
>>>>> > >>>>> compile with SWORD trunk, as this capability was added about 12<br>
>>>>> > >> months<br>
>>>>> > >>>>> ago. Or with the soon to be release 1.9.0.<br>
>>>>> > >>>>><br>
>>>>> > >>>>> Hope this clears things up a bit.<br>
>>>>> > >>>>><br>
>>>>> > >>>>> Troy<br>
>>>>> > >>>>><br>
>>>>> > >>>>><br>
>>>>> > >>>>> On 1/3/20 9:41 PM, Gary Holmlund wrote:<br>
>>>>> > >>>>>> John,<br>
>>>>> > >>>>>><br>
>>>>> > >>>>>> I would like to know this also. The unlock is implemented in the<br>
>>>>> > >>>>>><br>
>>>>> > >>>>>> sword library. Perhaps you can get an answer at <a href="http://crosswire.org" rel="noreferrer" target="_blank">crosswire.org</a><br>
>>>>> > >>>>>><br>
>>>>> > >>>>>> Gary Holmlund<br>
>>>>> > >>>>>><br>
>>>>> > >>>>>> On 12/30/19 4:29 PM, John A. Sullivan III wrote:<br>
>>>>> > >>>>>>> Hello, all. I was absolutely thrilled to see the Lockman<br>
>>>>> > >> Foundation<br>
>>>>> > >>>>>>> now appear in the bookshelf options and I downloaded the NASB<br>
>>>>> > >> module.<br>
>>>>> > >>>>>>> I was about to purchase a key from Lockman but I see notes<br>
>>>>> > >> on-line<br>
>>>>> > >>>>>>> that<br>
>>>>> > >>>>>>> the module cannot yet be unlocked and is only for testing. I<br>
>>>>> > >> don't<br>
>>>>> > >>>>>>> know if those are old notes.<br>
>>>>> > >>>>>>><br>
>>>>> > >>>>>>> If I purchase a NASB key, can I use it to unlock the NASB module<br>
>>>>> > >> in<br>
>>>>> > >>>>>>> Bibletime? Thank you for your dedication to this invaluable<br>
>>>>> > >> project -<br>
>>>>> > >>>>>>> John<br>
>>>>> > >>>>>> _______________________________________________<br>
>>>>> > >>>>>> bt-devel mailing list<br>
>>>>> > >>>>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > >>>>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> > >>>>>><br>
>>>>> > >>>>> _______________________________________________<br>
>>>>> > >>>>> bt-devel mailing list<br>
>>>>> > >>>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > >>>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> > >>>><br>
>>>>> > >>>> _______________________________________________<br>
>>>>> > >>>> bt-devel mailing list<br>
>>>>> > >>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > >>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> > >>><br>
>>>>> > >>> _______________________________________________<br>
>>>>> > >>> bt-devel mailing list<br>
>>>>> > >>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > >>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> > >>><br>
>>>>> > >><br>
>>>>> > >><br>
>>>>> > >> _______________________________________________<br>
>>>>> > >> bt-devel mailing list<br>
>>>>> > >> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > >> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> > ><br>
>>>>> > ><br>
>>>>> > > _______________________________________________<br>
>>>>> > > bt-devel mailing list<br>
>>>>> > > <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > > <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> > ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> > _______________________________________________<br>
>>>>> > bt-devel mailing list<br>
>>>>> > <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> ><br>
>>>>> ><br>
>>>>> > _______________________________________________<br>
>>>>> > bt-devel mailing list<br>
>>>>> > <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> > <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>> ><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> bt-devel mailing list<br>
>>>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> bt-devel mailing list<br>
>>>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> bt-devel mailing list<br>
>>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>>><br>
>>> _______________________________________________<br>
>>> bt-devel mailing list<br>
>>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> bt-devel mailing list<br>
>> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
>> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
> <br>
> _______________________________________________<br>
> bt-devel mailing list<br>
> <a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
> <br>
<br>
<br>
_______________________________________________<br>
bt-devel mailing list<br>
<a href="mailto:bt-devel@crosswire.org" target="_blank">bt-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/bt-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br>
</blockquote></div>