Paul Colomiets wrote: > Hi Alex, > > On Thu, Sep 18, 2014 at 9:30 PM, Alex Elsayed > <eternaleye@xxxxxxxxx> wrote: >> Note that the timeout is (in a sense) an artifact of the API, not the >> protocol. In particular, I'm tossing around a design for a pure-Rust >> implementation (like mangos was for go), which creates individual >> exchanges from AF_SP_RAW objects. >> i.e. you have a SURVEYOR object, you call .ask(query) on it, and this >> returns a Survey. The Survey has a .iter() method, allowing you to >> iterate over responses (lazy lists!) as they arrive, and signaling >> end-of-list at the timeout. >> > > Hm, by coincidence I'm coding pure-Rust implementation too :) Is your > implementation public? Nah, still in the pure design stage. >> This makes it trivial for a caller to act on the first response, and not >> wait for the timeout. >> > > It's easy to act on the first response. But timeout is essential to > handle failures (when no reply received). Hence giving e-o-l. The iterator API is pretty perfect for survey responses: http://doc.rust-lang.org/std/iter/trait.Iterator.html#tymethod.next fn next(&mut self) -> Option<A> Someone who only wants the first would call .iter().next() - it would wait until it either receives something or hits the timeout (whichever comes first), and return Some(message) or None as appropriate. Rinse, repeat. >>> IIRC, our discussion with Martin have come to conclusion that it's >>> possible to make subscriptions good enough for the pattern without >>> additional semantics. I can recall details if somebody would try to >>> implement it. >> >> Well, I'm going to be writing a mail about a generic subscription scheme, >> so your details would be nice to see. >> > > Okay, I'll follow up soon. >