Re: [reSIProcate] Questions about resiprocate roadmap

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Gregor,

Thanks for your help with this project lately, and your interest in improving and moving resiprocate forward.  I've marked up your email with my personal opinions or views.

I hope you get responses for others as well.  :)

...

On Tue, Mar 6, 2018 at 3:24 PM, Gregor Jasny via resiprocate-devel <resiprocate-devel@xxxxxxxxxxxxxxx> wrote:

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel


---------- Forwarded message ----------
From: Gregor Jasny <gjasny@xxxxxxxxxxxxxx>
To: resiprocate-devel@xxxxxxxxxxxxxxx
Cc: 
Bcc: 
Date: Tue, 6 Mar 2018 21:24:56 +0100
Subject: Questions about resiprocate roadmap
Hello,

I'd like to share some thoughts and ask some questions about the future
roadmap of resiprocate.

* Schedule for stable 1.11 release *

It's been a long time since the last resiprocate stable release. The
first 1.11 alpha was tagged in November 2016, the first beta in January
2017. Debian seems to have picked up those betas and ships them in the
stable distribution release.

Since the last beta a lot of bug fixes went into master. Also
resiprocate is now compatible with OpenSSL 1.1 which is crucial for most
Linux distributions because they try to phase out OpenSSL 1.0

Do you see any blockers preventing a 1.11 release or do you have patches
that should definitely be part of an upcoming stable release? What's the
release process for a new stable resiprocate?

[Scott]  Daniel Pocock was championing the resiprocate release process.  He's been a little MIA lately.  But the last time I talked to him, he was interested in getting a release out there with the OpenSSL 1.1 support in it.  I'm hoping he will respond to this.  :) 

 

* Switch to C++11 *

At $Company we use resiprocate in a C++11 (and soon C++14 code base).
Resiprocate's use of auto_ptr also on external interfaces gives us some
deprecation warnings for auto_ptr. Surerely we could silence those, but
AFAIR the final C++17 standard removed auto_ptr completely. So users of
resiprocate will have to enable special C++ standard library
compatibility flags, soon.

What do you think about moving to C++11 after the 1.11 release has been
branched off?

[Scott]  I'm in favour of this move.  I would like to understand if anyone out there would be negatively effected by this move.   ie:  Are there some users that are relying on older compilers, in particular older embedded compilers?   This means VS2015+ for Windows users. 

 

* Google Test as a test driver *

In several projects I used Google Test (and Mock) as a testing
framework. If you don't abuse it it results in elegant and nicely
readable tests. Also any detected errors are pretty descriptive and help
the developer to figure out what's going on.

Google Test supports fusing all own internal source files into one
single file so embedding into a project isn't too intrusive. I prepared
a test branch with a single converted test here:

https://github.com/gjasny/resiprocate/tree/add-google-mock

Google Test supports grouping of test cases into test suites and
theoretically we could create a single unit test binary per library.

[Scott]  I don't have a strong opinion on this.  Because of the complication of building our current tests in windows (needs a batch file), I don't think they actually get built and run much right now (on Windows).  If the Google Test framework is easy to build in windows and makes running these tests easier, I'm in favour.  However, Keep in mind we do have a set of unit tests for dum and repro (TFM tests) that are currently using the cppunit test framework, so bringing in another unit test framework, might add complexity.

 

* clang-format rules file *

Regardless of how hard I try, there are always some formatting errors in
my pull requests.  How about creating a clang-format file with the
preferred formatting and add it to the repo? One could the use 'git
clang-format' (or standalone clang-format) to format any patches to the
desired style.

[Scott]  I don't know much about clang-format tool, but I'll assume it is a tool to format code to our preferred style.  Anything to help new developers with that is a good thing.  I say, go for it.  We could also add a config file for Visual Studio settings as well.

 

* CMake buildsystem

My workstation OS is right now MacOS so there is no up-to-date
buildsystem with IDE support within the resiprocate repository. In the
past there was an initiative by Francis Joanis and Byron Campen to add
the CMake buildsystem. I picked up their work and adjusted it to the
current code base.  You can find a proof-of-concept that builds rutil,
resip, dum, reflow, and reTurn here:

https://github.com/resiprocate/resiprocate/pull/107

It works with CLion, Xcode and Ninja/Make on MacOS and Ubuntu 16.04.
I'll test (and probably fix) it on Windows later.  My general question
would be if there is interest in CMake at all and if you could imagine
to remove the Visual Studio solutions and projects in favour of CMake to
reduce maintenance cost. (Same question for autotools).

[Scott]  The build system for linux has changed a number of times.  We originally had a home grown make system, and a rudementary autotools build for some embedded compilations, both were replaced by a more full implemented autotools build by Danial Pocock (I beleive) - this is what is used today.  To date, no solution we have has been able to sync linux and Windows builds, so if we could find a solution for that, that would be great.  I think Daniel has spoken of some ideas in this area in the past (CMake/Ninja I think).  I have a number of customers using the Visual Studio solution and project files and I believe having these readily available is one of the draws for Windows users to resiprocate.  However, if CMake is able to produce Visual Studio solutions and projects we might get the best of both worlds, at the price of the additional complexity to download and install CMake and generate the files - or maybe we could just check-in the generated files?   I don't know CMake enough to really answer this question.

 

Thank you for your feedback!


Cheers,
Gregor