Today clients have to maintain a state(elapsed time) with themselves to execute a command in the future.
Currently if i want to delete a key lets say after 10 mins i can use the set command with expiry time to do so, similarly if i want to set a key 10 mins in the future i should be able to do that as of now there us no way to do that, so this proposal expects simillar to expiry time 3 new commands that could be added
1. TIMEOUT <delay in milliseconds> <any redis command> returns handle as integer
2. INTERVAL <delay in milliseconds> <any redis command> returns handle as integer
3. CANCEL <handle> returns 1 if cancelled successfully or 0
4. ERROR <handle> reports out any last known error on the given handle as string.
The "any redis command" argument means any redis commands which will be executed in the future, this will provide lot of flexibility to simply execute any valid command in future including scripts.
Comment From: oranagra
@LRagji what are the disadvantages of dong that from the client side?
for expiry, we wanna make sure no one has access to the value (even if the key isn't deleted) after it's expired. deleting it by a client could have race conditions. i.e. there are cases where the key isn't deleted, but would not be readable.
for expiry the TTL is registered in the key, and if the key is deleted, and replaced by another one, the TTL is reset. but with the feature you're proposing, it's hard to be sure which key you'll be overriding when you'll execute that future command (unless we somehow pair it with a WATCH type transaction).
@itamarhaber have you ever encountered a similar request?
Comment From: LRagji
@oranagra Thanks for taking a look, one disadvantage you already mentioned race condition what can happen with deletes can happen with addition/any other command as well.. Anyhow following are the points: In all morden application redis is like a data server(centeral singleton point) if clients have to execute a command in future they will have to maintain a timer on their side(can be reffered as state, which is frowned upon when writting H scalled application), while redis maintaining a central timer makes sense, Today people abuse(sort of) expiry time of a key as a timer and listen to keyspace events this could be rectified by using this command and publishing an event on pubsub or adding an item to stream using the future command, from a consumers perspective it make redis as the only dependency needed todo any fututre things instead of currently reaching out to cron job or other mechanism.. hope this makes sense..