libzmq11 is not enough, as said, until this is usable c++17 will be old. C++14 is indeed a bugfix version of C++11, but a very required one. C++17 is big and important, do not believe what some less relevant people write in the net. the next big thing is c++20, modules, concepts, maybe even network. hopefully reflections Please, those who not like it, I know Martins post about C++, ignore this. If you are not interested in a modern C++ zmq implementation, this is OK, but leaf this topic alone. Modernizing the existing implementation is not an option, using it as a templat to look what to do, and how - or how not - is an option. maybe a modern C++ implementation will ever exist and this is just discussion, but I find it nice that I am not the only one thinking about that. and who knows, if one person was able to make a zmq implementation in java, why not in modern c++ I think it is enough to be able to communicate with a libzmq implementation
/Harald 2017-05-19 18:24 GMT+02:00 Doron Somech <somdo...@gmail.com>: > We need to maintain libzmq as it the stable repository. I suggest a new > project, maybe called libzmq11. > > I think we should fork and update the code and not a rewrite. IMHO Rewrite > will fail, as other rewrites attempt failed. > > Regarding porting ongoing pull requests, I don't think we need to do that. > As other port of libzmq (NetMQ and JeroMQ) don't port every pull request. > If a user want to port a solution to a problem they can just send a pull > request. > > It is very important to maintain the same API as libzmq, as this will what > make users upgrade to the new version. We can mark the entire API as > obsolete, make a new one which is using C++11 (and can be called from other > languages and frameworks) but support the old API none the less. > > The main problem I see with this project is that 99.5% of the users of > zeromq don't care. They will not benefit directly from the upgrade. They > will benefit if the new version will be more active and will solve new > problems. > > So, to summarize: > 1. Fork, don't rewrite > 2. Use C4 > 3. Maintain the same API > 4. Obsolete old API and create new cooler API (if you really want to) > 5. Find a way users will benefit from the move > 6. It will take time, years probably, be patient > > > > On Fri, May 19, 2017 at 5:00 PM, Aram Santogidis <aram.santogi...@cern.ch> > wrote: > >> I'm happy that you guys like the idea and are willing to contribute. >> >> I see two separate issues from the remarks made so far. >> >> 1) Fork and modernize current codebase or write from scratch. >> 2) Update libzmq or create a new ZeroMQ project under a different name. >> >> The point 1) has to do with the technical aspects of the undertaking. >> The point 2) is related to ZeroMQ project managemnt/policy matters. >> >> Doron, I like your suggestion about forking instead of starting from >> scratch. What would be your position on point 2)? >> For me this is the sticking point and it is not obvious which option is >> best. >> >> If changes will be committed back to libzmq then compatibility will be >> broken for legacy systems from a certain version and beyond. The >> alternative option of creating a new project potentially leads to >> (community) resource fragmentation and "branding" issues. >> >> Regarding C++11,14... well I think the question at hand is not which >> exact version of C++ should be adopted but rather if the project will >> follow the evolution of the language and related technologies, with >> whatever "phase" difference serves best the community. >> >> PS: Does anybody know how big is the usergroup that runs ZeroMQ on >> Windows XP and such? Not even Microsoft support XP anymore. >> >> Cheers, >> Aram >> >> >> >> On 19.05.2017 15:21, BJovke . wrote: >> >>> I have a feeling that C++14 and C++17 are just improvements of C++11. >>> C++11 is the game changer, 14 and 17 don't bring ground breaking stuff. >>> >>> I would be also happy to contribute to C++11 libzmq but I'm not sure how >>> much stuff I can do. >>> I'm currently not familiar with inner workings of libzmq enough detailed >>> to be confident to rewrite it, although I'm reading the docs and code day >>> by day. >>> My time to spend is questionable, sometimes I have a lot of time and >>> sometimes I cannot contribute for days or even weeks. >>> >>> There are also many aspects of libzmq which make it hard to adopt the >>> code, instead requiring complete rewrite: >>> >>> >>> >>> >>> 2017-05-18 20:29 GMT+02:00 Jens Auer <jens.a...@betaversion.net <mailto: >>> jens.a...@betaversion.net>>: >>> >>> >>> Hi, >>> >>> I would be happy to contribute to such a project, even if many users >>> will stay with the "old" code. For me, it is a great way to learn >>> something. I would also be happy to aim for C++14 or even C++17 once >>> it is officially released. I think structured bindings and the new >>> if (init; condition) will be very helpful. C++17 also has >>> std::optional. >>> >>> Cheers, >>> Jens >>> >>> -----Ursprüngliche Nachricht----- >>> Von: zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org >>> <mailto:zeromq-dev-boun...@lists.zeromq.org>] Im Auftrag von Aram >>> Santogidis >>> Gesendet: Donnerstag, 18. Mai 2017 10:57 >>> An: ZeroMQ development list >>> Betreff: Re: [zeromq-dev] Porting libzmq to C++11 >>> >>> Hi, >>> >>> a good reason to modernize the codebase, or even better to create a >>> new project ala libzmq11, is to help its evolution with new >>> networking technologies and software engineering practices. >>> >>> As an example, consider the difficulties many faced (including >>> myself) in extending ZeroMQ to support RDMA-based networking >>> interfaces. The current design and implementation is hostile to such >>> extensions. >>> Honestly, C++98 or not, I think it still can be done but with major >>> cost in development effort and additional complexity to an already >>> complex codebase. >>> >>> Moving to C++11 and beyond is not merely an argument of fashion, as >>> some of you implied, but it is vital for its future. >>> C++ and related technologies evolve and libzmq stays behind. New >>> developers are reluctant to contribute once they have a look at the >>> current design and implementation (old school C++ roughly speaking). >>> >>> Think for example when networking will be included in the standard, >>> how much ugly code that juggles platform differences could be >>> eliminated from the current implementation. Same applies for >>> threading, which is in the standard since C++11. >>> >>> I don't underestimate the importance (and the size?) of the current >>> userbase. I'm aware from first-hand experience about some fairly >>> critical software that relies on libzmq. >>> >>> I guess the idea is to create i) a new project in the ZeroMQ >>> organization that ii) implements ZMTP and iii) the non-depricated >>> ZMQ socket types. The public API of libzmq should be a subset of the >>> libzmq11 so that will facilitate the transition of users, in the >>> long term, that do not run on legacy systems. >>> >>> I will happily contribute to such an effort provided that there will >>> be at least one or two experienced members from the community that >>> will join this effort. >>> >>> Cheers, >>> Aram >>> >>> >>> >>> >>> >>> On 17.05.2017 16:54, BJovke . wrote: >>> > Well, you're right. There must be a good reason for such an >>> undertaking. >>> > I too feel that C++11 itself is not good enough reason. >>> > Anyway there has to be enough people willing to contribute to it. >>> > >>> > I was just saying this because no idea should be discarded right >>> away, >>> > but for sure there needs to be a valid need and reason for it. >>> > >>> > Greetings. >>> > >>> > 2017-05-17 16:15 GMT+02:00 Doron Somech <somdo...@gmail.com >>> <mailto:somdo...@gmail.com> >>> > <mailto:somdo...@gmail.com <mailto:somdo...@gmail.com>>>: >>> > >>> > What will be the benefit from moving to C++11? And more >>> important >>> > what is the benefit from having two projects? one supporting >>> C++11 >>> > and one not? >>> > >>> > I think that maintaining two repositories is hard and not >>> sure for >>> > what cause? >>> > >>> > Anyway, if some one want to do it, in the zeromq philosophy, >>> please >>> > fork and add the project to the zeromq organization. >>> > >>> > On Wed, May 17, 2017 at 4:29 PM, <li...@chuckremes.com >>> <mailto:li...@chuckremes.com> >>> > <mailto:li...@chuckremes.com <mailto:li...@chuckremes.com>>> >>> wrote: >>> > >>> > >>> > > On May 17, 2017, at 7:56 AM, BJovke . <bjo...@gmail.com >>> <mailto:bjo...@gmail.com> <mailto:bjo...@gmail.com >>> >>> <mailto:bjo...@gmail.com>>> wrote: >>> > > >>> > > Hello. >>> > > >>> > > Libzmq is not even fully C++ compliant: >>> > > - There's no exception handling. >>> > > - There are no RAII principles implemented. >>> > > - Parent/child object hierarchy is loose or not >>> implemented, all of the burden of proper order of calls is on >>> programmer. >>> > > >>> > > And so on... >>> > > >>> > > C++11 is really a remarkable feat of engineering and me >>> personally like to see fully C++11 implemented software. >>> > > Unfortunately, for libzmq this would require >>> substantial rewrite of the library. >>> > > >>> > > Maybe there's an option to create another parallel >>> branch to existing libzmq or even create another product, for >>> example "libzmq11"? >>> > > On the wire this could be 100% compatible with >>> non-C++11 libzmq but there would be 0% chance to compile older >>> projects with it. >>> > >>> > This is a good time to bring out some old blog posts. >>> Martin >>> > Sustrik was the original developer of libzmq. He had some >>> > thoughts on why he should have written the library in C >>> instead >>> > of C++. Here you go: >>> > >>> > http://250bpm.com/blog:4 >>> > >>> > http://250bpm.com/blog:8 >>> > >>> > >>> > >>> > _______________________________________________ >>> > zeromq-dev mailing list >>> > zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> >>> <mailto:zeromq-dev@lists.zeromq.org >>> <mailto:zeromq-dev@lists.zeromq.org>> >>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >>> > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>> >>> > >>> > >>> > >>> > _______________________________________________ >>> > zeromq-dev mailing list >>> > zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> >>> <mailto:zeromq-dev@lists.zeromq.org >>> <mailto:zeromq-dev@lists.zeromq.org>> >>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >>> > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>> >>> > >>> > >>> > >>> > >>> > -- >>> > >>> > Jovan Bunjevački. >>> > >>> > >>> > _______________________________________________ >>> > zeromq-dev mailing list >>> > zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> >>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >>> > >>> _______________________________________________ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> >>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> >>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> >>> >>> >>> >>> >>> -- >>> >>> Jovan Bunjevački. >>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org >>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
