I have already posted about the roadmap plans for v2.0 (weaver's needle). Most of that work is targeted around integrating our new technologies we have discussed on the mailing list and for which contributors have work in progress patches. One project we will not be tackling in 2.0 is simplification of the code base.
In discussions with Angus Salkeld, We have decided to leave the code base for the infrastructure for 1.0/2.0 mostly untouched (except where bug fixing is needed). We will add service engines and some other requested features to the code base which are hopefully surgical and do not disrupt the behaviour of corosync. In 3.0 we will also introduce new features depending on where the community wants to put their work in. One gap we have is a good way to share data around without using messages - Honza has shown some interest in that project and will be making progress towards a solution in the 3.0 timeframe. In version 3.0, we will continue our trend towards a more componentized architecture. If you have had a look at 1.y.z, you will notice most components in the system have a component design to them already. These include things like logsys, coroipc, hdb, poll, plug in loader, etc. Unfortunately in the mad dash to make the software work well, some of these internal interfaces or their implementations within are just bordering on or are too complex and need some rework. The activity of reworking those infrastructure components will take place in the libqb project. We will remove these infrastructure components from Corosync 3.0 and then depend on libqb for that functionality. Corosync will then only act as a HA developer toolkit (providing its existing API set, service engines, and protocol). Angus has already made some great progress in simplifying the code base and reusing some common design elements. One of these is the chunked ring buffer mechanism using shared memory. This ring buffer is implemented currently separately in ipc and logsys. Over time, Angus plans to separate out the ring buffer from these two systems. The result? Less lines of code Individually unit-testable components that don't require a full cluster to run. Focused performance tuning around one code base for one set of target designs Focused towards high performance client server application developers The ring buffer concept is just one idea Angus has. Angus has many other great ideas for simplification of the code base. I invite you to join in his development especially if you are interested in some real cutting edge posix high performance systems programming. http://www.libqb.org Keep in mind this kind of effort is not going to happen overnight. This is what some of the core corosync developers have discussed for the next 2-3 years of development. If there are gaps we have which are not addressed, please let us know. Regards -steve _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
