On Tue, Mar 1, 2011 at 6:34 PM, Ian Barber <[email protected]> wrote:
> I think that this ties into the discussion of making SWAP a device anyway - > in my mind this kind of persistance and recovery should be pluggable, and it > really should be implemented as some sort of persistence device. If there > can be hooks in the library to making building this kind of thing easier > then that would be great - not sure what they would be though! There are two points here, IMO. One, the semantics of SWAP are "a hard disk extension of the in-memory message queue", and it is sensible to ask whether that can be recovered after failure. Obviously it's work, someone will have to make changes, but are the semantics logical? Yes, totally. Two, do we also need semantics for reliable message delivery? Yes, we do, and strangely enough it's something I'm working on for the Guide. Rust-based queues are feasible but they have their own challenges, and they do not overlap with SWAP afaics. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
