Hello Garret,
great to hear that you are stepping back up!
In the immediate future there won't be any changes to nanomsg except that IJust to add my comments while browsing the sources: I also found that*src/aio/pool.c* is a dummy placeholder. Implementing a proper thread pool might possibly increase performance.
will now resume spending time on it and trying to wrap things up for a 1.0
release. Basically I will pick up where I left off back in January. However it
may take a little bit of time for me to reacquire my context so please be
patient while I do so.
As far as features go, I don't expect to see more for 1.0. There is a PRI am with you on this one. It's a good idea to leave this after the 1.0 release. I have seen some possible pitfalls and I *might* even change the implementation if it seems problematic. It would be good to have a chat over this...
relating to changing the allocation scheme to support a new transport. I've not
fully reviewed that yet but I plan to - I think the contributor is on the right
path here. But I suspect that we are going to defer integrating that work until
after 1.0 releases to minimize risk and give me time to review it, and
hopefully also give time for the transport work that uses these interfaces to
get some mileage - thereby increasing our confidence in the changes.
Per the majority of the nanomsg and the existing github contributors to
nanomsg, I'm resuming my role as leader/maintainer but also as BDFL for nanomsg.
In the immediate future there won't be any changes to nanomsg except that I
will now resume spending time on it and trying to wrap things up for a 1.0
release. Basically I will pick up where I left off back in January. However it
may take a little bit of time for me to reacquire my context so please be
patient while I do so.
My immediate goals are to stabilize the code and release a 1.0. I am also
working to increase the size of the leadership so that there will be a backup
in case I get hit by a cement truck. And I will be delegating some of the
effort by leveraging resources here. Expect more from me on this in the coming
days.
As far as features go, I don't expect to see more for 1.0. There is a PR
relating to changing the allocation scheme to support a new transport. I've not
fully reviewed that yet but I plan to - I think the contributor is on the right
path here. But I suspect that we are going to defer integrating that work until
after 1.0 releases to minimize risk and give me time to review it, and
hopefully also give time for the transport work that uses these interfaces to
get some mileage - thereby increasing our confidence in the changes.
I do expect to roll out cmake and when I do to eliminate autoconf support. If
anyone has vehement opposition to this, please respond with supporting evidence
or argument why cmake instead of autoconf is unacceptable.
I do intend to remove the tcpmux transport. I think this is problematic for a
variety of reasons - it isn't portable, requires root to operate, and frankly
the problems it tries to solve can better be addressed with url based routing
and the websocket transport. While libnanomsg doesn't fully achieve that today
on its own, solutions using another HTTP router or mangos devices are available
today. As with the removal of autoconf, if this is going to cause major
problems for you I want to hear about it along with an explanation as to why
the websocket based solution is inadequate as a replacement.
That's it for my immediate agenda.
Thanks to those who've offered their support.
I'm looking forward to celebrating the release of 1.0 but I want it to be a
release we all feel great about. I expect we will get there very soon.
Thanks again.
- Garrett
Sent from my iPhone
