> Perhaps. What problem would you be solving with TTLs, which is an
> issue today? ("Lack of feature X" is not a valid problem statement for
> feature X).There's a need to send certain type of messages which have sort of "use-by date" attribute. I.e. client may want to define this attribute and receiving peer should pay attention to it. What it would give? It would give a control over queued messages. Say, if I sending messages which are "valid" _only_ when peers connected and "not valid" when peers aren't connected. Here "valid/not valid" is defined via "use-by date" message attribute. Receiving peer may check "use-by date" and recognize if gotten message was too long inside somebody's queue, and take some actions: log, throw error, silently discard a message, or even collect a message inside so called "dead letter" queue . Btw, essentially, today 0mq defines "use-by date" as infinite. And proposition is to make this thing configurable. 2013/12/28 Pieter Hintjens <[email protected]> > On Fri, Dec 27, 2013 at 1:26 PM, artemv zmq <[email protected]> wrote: > > > And all queueing solutions do have TTL . > > Perhaps. What problem would you be solving with TTLs, which is an > issue today? ("Lack of feature X" is not a valid problem statement for > feature X). > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
