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