Work in progress. The HTTPS test is failing, but I'm not sure why yet. Unclear if the client is failing to verify the server's cert, or the server is failing to verify the client's cert. I'm also not happy with having to change the API for supplying a client TLS credentials (native-tls only supports PKCS #12), but maybe this API is actually better.

I am building some tooling to not only added keys and directories but also users, roles and grants. This doesn't seem possible with this crate. If I'm wrong, a pointer to how these types of entries can be written as plain nodes would be helpful. Otherwise, an additional module or set of modules to support working these types of data in a cluster would be fantastic.

I upgraded all deps, with new hyper version we are no more forced to carry around a tokio core handler reference. The only stylistic doubt I have is about impl From for Clusterinfo, the conversion from String can fail, From can't fail, so I've used log crate to log the failure without panic-ing...

I'm using the watch timeout set to 10s. If we've not received a change notification by then I ping the downstream service anyway and then restart the watch. Unfortunately, this leaks a connection every 10s if there is no activity in etcd.

I assume this is due to the rust-etcd watch integration with hyper. Let me know if you would like any specific diagnostics.

Implementation of the leader statistics API.

Curious if you think this is the right approach for this. I'm a bit wary that it encodes the current API for these statistics too statically. Alternatively, it could expose something more like the Json object itself, which can be queried dynamically.

Also curious if you think the leader_stats method on Client is the right place/name for this.

Note that I added a couple error types: an IO error, which can happen when reading the response into a string, and a JSON decoding error, which happens if the response doesn't match the expected data structure. Let me know if you like that approach and I'll change the other methods that currently panic in those cases; if not, I can make this consistent with everything else.

Seems that Cargo will consider a requirement string without a prefixed operator equivalent to prefixing a carot: 1.2.3 == ^1.2.3.

https://github.com/rust-lang/cargo/issues/1418 https://github.com/steveklabnik/semver/issues/81

As for the 'semver patches shouldn't break things' argument, https://github.com/serde-rs/serde/issues/379

This is an idea I had while going through and using try! everywhere we're reading the response into a string in order to propagate IO errors instead of panicking. It works well, but a potential downside is that it accepts StatusCode::Created as a successful response code for all requests, rather than just for "set" operations as before. Not sure whether or not that's a dealbreaker for this approach.

(Based on #2.)

When getting the root node /, created_index and modified_index are not present.

Perhaps a better abstraction for this type is needed when all fields are optional. 😄

   Compiling etcd v0.5.4
/home/kallisti5/.cargo/registry/src/github.com-1ecc6299db9ec823/etcd-0.5.4/build.rs:27:37: 27:50 error: mismatched types [E0308]
/home/kallisti5/.cargo/registry/src/github.com-1ecc6299db9ec823/etcd-0.5.4/build.rs:27             serde_codegen::register(&mut registry);
                                                                                                                           ^~~~~~~~~~~~~
/home/kallisti5/.cargo/registry/src/github.com-1ecc6299db9ec823/etcd-0.5.4/build.rs:27:37: 27:50 help: run `rustc --explain E0308` to see a detailed explanation
/home/kallisti5/.cargo/registry/src/github.com-1ecc6299db9ec823/etcd-0.5.4/build.rs:27:37: 27:50 note: expected type `&mut syntex::Registry`
/home/kallisti5/.cargo/registry/src/github.com-1ecc6299db9ec823/etcd-0.5.4/build.rs:27:37: 27:50 note:    found type `&mut inner::syntex::Registry`
error: aborting due to previous error
error: Could not compile `etcd`.

To learn more, run the command again with --verbose.

Hi. Do you support etсd 2.2?

On etcd 2.2 i have error: panicked at 'called Result::unwrap() on an Err value: ParseError(SyntaxError("trailing characters", 1, 5))', ../src/libcore/result.rs:688

let client = Client::default(); let r = client.get("some_key", true, true);

etcd version - 2.2.3.

v0.7 looks like a good step forward. However, from my point-of-view, the release note misses off one significant change: etcd::Client is no longer Send (or Sync). This means that it is difficult to use in a multithreaded application, even when wrapped in an Mutex.

It appears that making hyper not suitable for multithreading might be deliberate. However, I don't think that needs to be a true of etcd::Client objects. It might even just be a matter of switching from using std::rc::{Rc,Weak} to std::sync::{Arc,Weak}.

Was it a conscious decision not to support multithreading? (If so, why? Performance?) Might you consider doing so?

error[E0277]: the trait bound `std::rc::Weak<std::cell::RefCell<tokio_core::reactor::Inner>>: std::marker::Send` is not satisfied in `std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>`
  --> src/bin.rs:12:5
   |
12 |     test_send_trait(arc_etcd);
   |     ^^^^^^^^^^^^^^^ `std::rc::Weak<std::cell::RefCell<tokio_core::reactor::Inner>>` cannot be sent between threads safely
   |
   = help: within `std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>`, the trait `std::marker::Send` is not implemented for `std::rc::Weak<std::cell::RefCell<tokio_core::reactor::Inner>>`
   = note: required because it appears within the type `tokio_core::reactor::Handle`
   = note: required because it appears within the type `hyper::client::Client<hyper::client::connect::HttpConnector>`
   = note: required because it appears within the type `etcd::http::HttpClient<hyper::client::connect::HttpConnector>`
   = note: required because it appears within the type `etcd::Client<hyper::client::connect::HttpConnector>`
   = note: required because it appears within the type `std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Mutex<std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>>`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<std::sync::Mutex<std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>>>`
   = note: required by `test_send_trait`

error[E0277]: the trait bound `std::rc::Rc<std::cell::RefCell<hyper::client::pool::PoolInner<tokio_proto::util::client_proxy::ClientProxy<tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RequestLine>, hyper::http::body::Body>, tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RawStatus>, tokio_proto::streaming::body::Body<hyper::http::chunk::Chunk, hyper::error::Error>>, hyper::error::Error>>>>: std::marker::Send` is not satisfied in `std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>`
  --> src/bin.rs:12:5
   |
12 |     test_send_trait(arc_etcd);
   |     ^^^^^^^^^^^^^^^ `std::rc::Rc<std::cell::RefCell<hyper::client::pool::PoolInner<tokio_proto::util::client_proxy::ClientProxy<tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RequestLine>, hyper::http::body::Body>, tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RawStatus>, tokio_proto::streaming::body::Body<hyper::http::chunk::Chunk, hyper::error::Error>>, hyper::error::Error>>>>` cannot be sent between threads safely
   |
   = help: within `std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>`, the trait `std::marker::Send` is not implemented for `std::rc::Rc<std::cell::RefCell<hyper::client::pool::PoolInner<tokio_proto::util::client_proxy::ClientProxy<tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RequestLine>, hyper::http::body::Body>, tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RawStatus>, tokio_proto::streaming::body::Body<hyper::http::chunk::Chunk, hyper::error::Error>>, hyper::error::Error>>>>`
   = note: required because it appears within the type `hyper::client::pool::Pool<tokio_proto::util::client_proxy::ClientProxy<tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RequestLine>, hyper::http::body::Body>, tokio_proto::streaming::message::Message<hyper::http::MessageHead<hyper::http::RawStatus>, tokio_proto::streaming::body::Body<hyper::http::chunk::Chunk, hyper::error::Error>>, hyper::error::Error>>`
   = note: required because it appears within the type `hyper::client::Client<hyper::client::connect::HttpConnector>`
   = note: required because it appears within the type `etcd::http::HttpClient<hyper::client::connect::HttpConnector>`
   = note: required because it appears within the type `etcd::Client<hyper::client::connect::HttpConnector>`
   = note: required because it appears within the type `std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Mutex<std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>>`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<std::sync::Mutex<std::result::Result<etcd::Client<hyper::client::connect::HttpConnector>, etcd::Error>>>`
   = note: required by `test_send_trait`

The demo code from https://docs.rs/etcd/latest/etcd/ does not compile with tokio 1.x After I managed to make it compile by using futures::compat, at runtime it will give error tokio::spawn failed (is a tokio runtime running this future?). does the author still plan to make it work with newer version of tokio ?

Some time in the last few commits, the watch_recursive integration test has started hanging (never completing) indicating a race condition. I'm not sure whether it was from a change to the library or an update of a dependency that caused it to start doing this, so I'm not sure of the root cause. Needs to be investigated.