Add optional delete parameter to get request #29

Open
alsonkemp opened this Issue Oct 24, 2012 · 4 comments

Projects

None yet

4 participants

@alsonkemp

"delete: delete returned items from the queue rather than placing them into a pending-delete queue"

Chat logs:
Alson Kemp
6:29 PM
so I have a bunch of log stuff in the queue and deleting items from the queue is where I spend a majority of my time.
Alson Kemp
6:31 PM
I don't mind if I lose a small percentage of items, so I'd love a optional parameter of "delete: delete returned items from the queue rather than placing them into a pending-delete queue"
In order to process 20 items, I have to do 21 requests and it'd be better if I could just do 1 (get 20 items).
Andrew Kirilenko
6:32 PM
so, basicly, get-and-delete request
makes sence
Alson Kemp
6:32 PM
even if that functionality is not supported by whichever MQ system you're using, building it into your app layer would save both of us cycles.

@odeits
odeits commented Oct 24, 2012

What about a multi delete endpoint?

@alsonkemp

What about a multi delete endpoint?
Actually, I think both features are good, complementary ideas.

Optional-Delete: fastest, but riskiest. Helps me 100%.
Multi-Delete: 100% slower-than-fastest_, but safer. Helps me 90%.
_ By which I mean, optional-delete costs me 1 request and multi-delete costs me 2 (get + multi-delete).

Obviously, you know your system and capabilities better than do I, so I'm happy to revise this ticket to reflect what you tell me you'd like to implement.

@paddyforan

Obviously, you know your system and capabilities better than do I

Oscar, despite all appearances, does not actually work for Iron.io :P Or, to be more accurate, we don't employ him. ;)

I like both proposals. I think we were kicking around the idea of a multi-delete a few months ago, but I'm not sure it ever went anywhere.

We've been lightly discussing the possibility of a new revision for our API. I can't promise the discussion will come to anything, but we'll definitely include these proposals in the conversation. Changing our API is a big deal (lots of client libraries, some of which we didn't author. Some people use our API directly. Etc.) so it'll take some time. Perhaps, if they aren't backwards-incompatible changes, we can issue a minor revision to the API to enable them. That would let us roll them out much quicker.

@petethered

Same issue... would love to see a delete on get option.

A large amount of my async tasks don't need guaranteed completion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment