[zeromq-dev] Why 0mq doesn't define TTL for message (for in-mem queue)?

[artemv zmq]

> 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 <ph at imatix.com>

> On Fri, Dec 27, 2013 at 1:26 PM, artemv zmq <artemv.zmq at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131228/930acebe/attachment.htm>