so-5-5
so-5-5 copied to clipboard
eao197
[en] On the road to SObjectizer-5.6
Motivation
Work on 5.5-branch started more than 4.5 years ago. In conditions when it was necessary to take into account compilers without a proper support of C++11, not speaking about C++14. Since then SObjectizer-5.5 is being developed with respect to old C++ compilers and with attempts to provide maximum source-code compatibility between versions inside 5.5-branch. SObjectizer-5.5 also inherited some design decisions from more earlier versions of SObjectizer-5.
As the result there are some flaws in design and implementation of SObjectizer. These flaws are the consequences of mistakes during designing SObjectizer's API and inabilities to use features from modern C++ standards. There is no way to fix those flaws without breaking compatibility between SObjectizer's versions.
It seems that there is no sense to continue development of 5.5-branch in 2019.
The goal of SObjectizer-5.6 development
The goal of SObjectizer-5.6 development is the creation of next SObjectizer version without a problems detected in 5.5-branch. The next SObjectizer version will keep the basic working principles of SObjectizer-5, but without 100% compatibility with SObjectizer-5.5.
What are planned for SObjectizer-5.6?
Remove all deprecated things
As result of 4+ years evolution of 5.5-branch a plenty of things were marked as deprecated. For example: so_5::rt namespace and send_delayed_to_agent function.
Those things are still present in SObjectizer-5.5 for the compatibility. But it is a time to cleanup SObjectizer's code base.
Every mbox will hold a reference to SObjectizer Environment
There is no way to get a reference to SObjectizer Environment from an mbox. But, in principle, it is possible for MPSC-mboxes. Alse one can get that reference from mchain and mchain can be transformed into mbox, but that mbox doesn't provides access to SObjectizer Environment.
As a result we have different versions of send_delayed and send_periodic functions in SObjectizer-5.5. In the next version of SObjectizer a reference to Environment can be obtained from any mbox. It allows to make unified versions of send_delayed and send_periodic functions, for examples: send_delayed(mbox, pause, args) and send_delayed(agent, pause, args).
Reduce count of ways to send a message
SObjectizer-5.5 has many ways to send a message. For example: several overloads of deliver_message in abstract_message_mbox_t class. It is the result of many years of SObjectizer's evolution.
It is necessary to remove some of old methods and classes intended for message sending and issuing of service requests. A couple of methods in abstract_message_t and environment_t + template functions send, send_delayed, send_periodic, request_value and request_feature should be enough.
Reduce count of event-handler's formats
Only two formats will be allowed in SObjectizer-5.6:
ret_type event_handler(mhood_t<msg_type>); // for messages and signals.
ret_type event_handler(const mhood_t<msg_type> &); // for messages and signals.
Support for ad-hoc agents will be removed
The experience shows that it is easy to declare an ordinary agent for some simple actions in modern C++. Because of that there is no sense to keep support for ad-hoc agents in SObjectizer.
Support for tuple_as_message will be removed
There is no need to support tuple_as_message after introduction of possibility to send messages of arbitrary user type (a type not inherited from so_5::message_t).
No public dispatchers any more
There were only public dispatchers in early versions of SObjectizer-5. Private dispatchers were introduced later. But now the private dispatchers are the recommended way to bind agents to some execution context.
Support for public and private dispatcher makes SObjectizer's API complex and this support is expensive in sense of SObjectizer's maintenance. Because of that only private dispatchers will be supported in SObjectizer-5.6.
Cleanup of API
Some duplicated method/functions and potentially dangerous methods/function (like those accept raw pointers) will be removed.
Where the source code of SObjectizer-5.6 will live?
Since May 2013 the source code of SObjectizer and related projects lives in Subversion-repository on SourceForge with an experimental mirror on GitHub. We plan to change that for SObjectizer-5.6.
The first reason is the speed of Svn on SF.net last year. Svn on SF.net is slow now. And sometimes the repository becomes unavailable during the problems with SF.net.
The second reason is a desire to have a simple integration with services like TravisCI (without a complex mirroring procedure).
The usage of GitHub looks like the main variant (with repository name like https://github.com/Stiffstream/sobjectizer-5-6). But some of SObjectizer's developers (eao197 as an example) don't like git and GitHub and prefer different tools.
Because of that there is an alternative: Mercurial-repo on BitBucket (with name like http://bitbucket.org/sobjectizerteam/sobjectizer-5.6). With mirror to GitHub (mirror of Hg repo much simpler than mirror of Svn-repo).
There is no the decision on this question yet.
Companion projects, like timertt and so_5_extra, will live in separate repos on the same hosting platform. Dependency management will be performed via MxxRu:::externals (like that is done now for so_5_extra).
Where the documentation for SObjectizer-5.6 will live?
This is an open question. There are three possible answers.
-
The documentation for new version will be placed in the Wiki on SourceForge. It means that all SObjectizer's doc will be at the same place. This case simplifies writing of new doc because big fragments from old doc can be reused easily.
-
The documentation will be placed in the Wiki of new repository. For example if BitBucket will be used for hosting of SObjectizer-5.6 code then the doc will be in Wiki on BitBucket.
-
The documentation will be placed on stiffstream.com like it is done for RESTinio's manual.
Which C++ standard will be used for 5.6-branch?
We want to use C++17. With minimal C++ compilers like GCC 7, clang 6 and Visual C++ 15.9.3. Or even GCC 8, clang 7 and VC++ 15.9.3.
We can reduce the our requirements to C++14 standard. But only if someone tell us why this is important. If nobody asks for C++14 support we will support only C++17 and newer versions of C++.
We won't support C++11. If you really need C++11 please consider commercial support for SObjectizer.
What is the timeline?
We expect two stages of SObjectizer-5.6 development.
The first stage is the cleanup of SObjectizer's code and forming of the very first SObjectizer-5.6 version. Plus the writing of documentation and manuals for the new version. As the result of this stage the version 5.6.0 should be released. We want to ship 5.6.0 at the end of Feb 2019 (if everything will go as expected).
The next stage will begin after release of version 5.6.0. This stage is for extension of SObjectizer-5.6 functionality. It means that since v.5.6.0 new features will be added only to SObjectizer-5.6, not to SObjectizer-5.5.
How long SObjectizer-5.6 will live?
We expect that SObjectizer-5.6 will be the actual SObjectizer branch till the end of 2019. We have no plans beyond that time point.
The actual lifetime of 5.6-branch will be dictated by SObjectizer's users. The more people use SObjectizer-5.6 in their projects, the longer lifetime for SObjectizer-5.6.
What will happen with SObjectizer-5.5?
Nothing.
We will maintain SObjectizer-5.5, fix defects and publish updates until the release of SObjectizer-5.6.0. After that moment the development and maintenance of SObjectizer-5.5 will be stopped.
If you want a maintenance for SObjectizer-5.5 then you can ask for commercial support.
How can you make an influence on SObjectizer's development?
We always listen to our customers and users. So you can tell us everything you want. For example: what do you want to see in next SObjectizer's version? What do you want to remove from SObjectizer? Do you agree with usage of C++17 or maybe you need C++14? Is it OK to host SObjectizer of BitBucket or maybe you can work with GitHub only?
Your answers to those questions make our further development of SObjectiver much easier.
I'm using your library for my master's thesis project. A simple application for serving machine learning models. I'm not C++ expert but library is very nice and makes is it easier to develop concurrent applications even for beginner like myself. Thank for your hard work.
I think moving SObjectizser to GitHub might definitely make your project more visible. Also moving documentation from sourceforge here would have been nice but your probably don't have time for that.
I will try to think off some other comments while I work with your library.
@atraastrum thanks for your comment.
Providing the docs for SObjectizer is one of the top priorities for us. Because of that we will spend necessary amount of time to writing and rewriting docs for the future version of SObjectizer.