[sword-devel] Announcing Sword++

[Peter von Kaehne]

Libsword needs to be working for all kinds of devices and in a million
of unanticipated environments. Now and in future.

It needs to work for module makers as much as for frontend makeers -
both existing ones and those we have not even thought of yet. 

Changes like dropping of utilities (diatheke for one, which is
extensively used by module makers) and bindings (again used ++ by
module makers) - need to be slow, reliable and consensual. And the
maintainers need to be slow, reliable and acting in consensus, too.
Plodders, more than revolutionaries.

Are you a plodder, seeking consensus?

Peter



On Sun, 2016-09-25 at 21:54 +0300, Jaak Ristioja wrote:
> Hello!
> 
> Sometime in May this year my efforts to improve the Sword library as
> the
> backend for BibleTime led me to create branch or fork of the Sword
> codebase, which I eventually called Sword++. The main goals for this
> were to (with respect to BibleTime development) improve the API,
> build
> system and overall code quality, modernize, and to try to fix any
> bugs I
> find when refactoring and reviewing the code. With experience as a
> C++
> backend engineer and being no Sword expert, my refactoring effort
> also
> serves the purpose of educating myself about Sword and its internals.
> While I'm just starting out and have barely touched the amount of
> work
> that needs to be done, I've already accumulated over 200 new commits
> to
> the Sword++ repository so far. So this seems to be a more-or-less
> reasonable time to publicly announce my publicly before the situation
> gets too awkward.
> 
> Before I proceed, I want to emphasize that none of this is meant to
> split or even stir up anything negative in the community. However,
> Sword++ is an initiative to stop and reverse the current bit-rot; it
> is
> more of a rescue effort and not a rebel event. Due to the sheer
> amount
> of work that needs to and can be done to reach these goals, it is
> evidently impractical for me to push and wait for every such change
> to
> work its way through the issue tracker and/or sword-devel and reach
> SVN
> trunk. To work around this costly threshold for contributing to the
> Sword library, Sword++ is now here.
> 
> Sword++ is not officially related to CrossWire. The code currently
> lives
> at https://github.com/swordxx/swordxx and as the initiator I'm
> currently
> idling alone on the #sword++ channel on FreeNode IRC. Feel free to
> contribute, file bug reports, pull requests etc. Also feel free to
> cherry-pick or merge any fixes back to Sword. I don't think I will
> (or
> have time to) flood sword-devel with emails about every bug (or
> technical, design or architectural issue) I find. I will try to
> notify
> about most severe security issues. Follow the git log if you're
> interested.
> 
> The code is in sync with enhancements in the Sword SVN trunk and for
> now
> I'll try to keep it that way, although I've changed the layout of
> source
> files etc extensively which makes merging harder. I'm currently
> targeting standard C++14, POSIX and Linux, with everything else
> having
> lower priority due to Sword++ currently having only one active
> developer. I've also dropped all the language bindings (which I don't
> intend on maintaining together with the Sword++ master branch), a
> bunch
> of legacy and unused code, tools and utilities etc. MSVC project
> files
> and autotools were dropped from the build system, which is now only
> based on CMake. Ftplib support was also dropped, cURL, CLucene 2,
> bzip2,
> xz and zlib are now unconditionally required by Sword++. There are
> also
> some API changes so switching from Sword to Sword++ requires some
> effort. See the git log for details and more.
> 
> There is a lot of uncertainty because this is just the beginning of
> the
> process. Currently Sword++ must be considered unstable. I haven't
> tested
> it much at runtime. I'm mostly doing code review, modernizing, fixing
> bugs and compiler warnings and static analysis warnings,
> despaghettification and deduplication of code, improving the API etc
> etc
> etc. Sword++ will try to stay compatible with existing Sword modules,
> but will probably propose amendments to the file formats and download
> protocols (e.g. to get rid of parsing the potentially fragile HTML of
> directory listings generated by the Apache HTTP server).
> 
> I hold in high respect both CrossWire and all who made the Sword
> library
> possible and am grateful for ALL of you who have enabled or
> contributed
> to Sword, and your work. I hope the Sword++ initiative will benefit
> our
> developer community, the end-users and so on.
> 
> Glory be to God!
> 
> Thank you and many blessings,
> Jaak Ristioja
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page