Closed grantr closed 3 years ago
The extra dependency would only be required for dev and for the nsq gemspec. I'd rather use a supported client library and have an extra dep than support a custom one long term. Thoughts?
@jnunemaker sorry for the confusion! This isn't the full NSQ backend. This is only an alternative for those scared of celluloid. It turned out to be easier to write than the real one.
A true NSQ backend (with krakow as the client library) is in progress at https://github.com/grantr/qu/tree/nsq. It works, but there are timing issues with the specs that I haven't resolved yet. I'll create a PR for that when it's ready.
@bkeepers can you add @grantr to qu or add me in some way that I can access settings? Seems easier to have him just work on qu in branches, rather than a fork.
Do you see NSQ being commonly used? I'm just wondering if it should just be in a separate repo. I don't feel strongly either way, but I know in the past we've tried to limit the officially supported backends.
@bkeepers can you add @grantr to qu or add me in some way that I can access settings?
Added him. I guess you can't give admin access to contributors on personal repos?
Yeah, I'd be cool with separate gem for nsq as well.
I actually think everything but qu-redis should be a separate repo. Can we create a qu org?
Stale.
This backend supports the NSQ HTTP api with no extra dependencies. It can only push, get queue size, and clear queues.
I split the backend shared specs internally into pushing specs (push, size, clear) and other. Future shared push specs should go in the
a pushing backend
group./cc @jnunemaker @bkeepers