[bt-devel] NASB Unlock Key
Jaak Ristioja
jaak at ristioja.ee
Sun Jan 5 06:31:17 MST 2020
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
>
More information about the bt-devel
mailing list