Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Hi guys! I was just wondering about the state of Nimbus, and what the plan is for the near future? I have noticed there aren't that much activity in merging PRs into master.
I read in some other issue that you have had problems with your build servers and that generally your couldn't find time for it. Is there something we the community can help with? I think many are willing to help out in getting a new version of Nimbus out in the wild!
Service Bus on Windows is getting a little bit of attention: http://blogs.msdn.com/b/servicebus/archive/2015/11/13/update-to-service-bus-for-windows-server-1-1-for-the-net-framework-4-6.aspx
But admittedly that's not much. Server 2016, whenever that's out, might bring with it some service bus updates. Another article on that blog, http://blogs.msdn.com/b/servicebus/archive/2015/08/25/service-bus-sdk-3-0-x-part-1.aspx, has a couple of comments in the discussion area of interest too.
Sorry for the radio silence... it's not personal :)
Yep it's a little neglected here, there are a couple of reasons.
So the combination of all of those things has meant that spending time on Nimbus has been a bit more mental overhead than I've had capacity for.
I want Nimbus to continue, I believe in it.
So here is where things are at.
We had a big talk the other day and decided that no, Nimbus isn't dead.
But Windows Service Bus is definitely starting to smell that way so we need to do something about that.
As I said before the biggest problem is the lack of progress on Windows Service Bus and the fact that we tied ourselves to that SDK thinking it would keep up.
If we could break that dependency we could split out transports and maybe look at something faster like Redis (which we did some experimenting with and it's many times faster than WSB and orders of magnitude faster than ASB).
We sat down today and started to hack.
The biggest thing that was woven through our code was our dependency on BrokeredMessage. Today we managed to break that dependency and get to an almost working state (The rest of it was actually quite easy, the abstractions held up pretty well).
What that means is we could split out and do multiple transports, so we can use the newer SDKs for Azure Service Bus and take advantage of some of the improvements there, and optimise the WSB version to take advantage of the on premise install (there are some things we can do there to make it better that hurt your billing when in Azure) so it's wins all around!
We've got some ideas on how to take advantage of Redis, which means re-implementing some of the things we've gotten for "free" with what we had. (Free of course comes with a high cost of getting them to actually work).
I won't go in to all the details here yet, but it does mean that a lot of the current issues and PRs go away with what will be version 3.0 of Nimbus. So I'll leave them there for the moment to make sure we capture everything people need to do, but there's no point pulling them in at this point. We'll probably put out a patch release of 2.0 in the next week with some of the small changes I've already pulled in.
What we're looking at doing also means pulling out some of the scariest code inside Nimbus like the custom task scheduler and long running tasks so the code should be a bit easier to get your head around for other contributors in the future.
So definitely very much alive here, we're really excited to work on it again and do a version 3 that is faster, more useful, and hopefully easier to work on.
I've also taken on peoples suggestions and set up a Gitter channel to discuss it. I won't promise I'll be around on it all the time, but it might be good to see who's around and what there doing.
That's it for now!
Cool stuff, thanks for the update! Are you planning to open issues for the major changes you're making? It would be good to have an open chat about what shape the messaging API is likely to take for people who want to write their own implementations (kafka is one that comes to mind for me)