If you want a nice new, clean and convenient API, why don’t you build one on top of the current API?
Manfred > Am 28.09.2016 um 16:49 schrieb Konstantin Maslyuk <kostyamasl...@gmail.com>: > > Thank you, Jaak, for your good starting. I still hope that your knowledge in > C++ development and Troy's experience in Sword development would unite in > development of next major libsword iteration (reword libsword2). I think you > both have many great ideas for that. > > I also expect from libsword2 more convenient api. Since we managed to work > with existing, it leave many questions and unobvious things (SWMgr that is > actually iterator, Upper/Lower bound that do not say where is module > beginning for new ones). A lot of code in Sword is hard to maintain, only few > people knows how it actually works. It is not look like good C++ code. And it > will never evolve if we will focus on elder devices. > > So I suggest to not extinguish any kind of energy here but to support. It is > so little here. > > As for me, i like elder devices, and at this moment they are in my priority. > > > Blessings. > От: Jaak Ristioja <mailto:j...@ristioja.ee> > Отправлено: 25.09.2016 21:56 > Кому: SWORD Developers' Collaboration Forum <mailto:sword-devel@crosswire.org> > Тема: [sword-devel] Announcing Sword++ > > 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@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > _______________________________________________ > 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
_______________________________________________ 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