etcd4j
etcd4j copied to clipboard
adohe-zz
Support v3 etcd api
Support v3 etcd api https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_reference_v3.md
@raoofm Sorry about reply so late, I just get more time to do this. What do you think about this? Do you have any good idea? I want to first implement all key-value interfaces.
I'll take a look at what you have. I'll be interested in this, if you need any help implementing.
I see a v3 branch will check that.
@raoofm I just add some init commits in v3 branch, this is far from complete, I want to keep this step by step and I will focus on this this week. Really appreciate your help if you have time. Thanks very much :)
@raoofm I am thinking about some implementation details, and I want to make this a good start. There are two proposals I have got: Proposal 1: Implement all services in one client:
public class EtcdClient {
/*
* KV service
*/
public ListenableFuture<?> range(RangeRequest request) {
}
public ListenableFuture<?> put(PutRequest request) {
}
/*
* Lease service
*/
public ListenableFuture<?> leaseGrant(LeaseGrantRequest request) {
}
public ListenableFuture<?> leaseRevoke(LeaseRevokeRequest request) {
}
}
Proposal2 Implement different service in different client, and write a wrapper client to aggregate clients:
public class EtcdClient {
public KV kv() {
}
public Lease lease() {
}
}
class KV {
public ListenableFuture<?> range(RangeRequest request) {
}
public ListenableFuture<?> put(PutRequest request) {
}
}
class Lease {
public ListenableFuture<?> leaseGrant(LeaseGrantRequest request) {
}
public ListenableFuture<?> leaseRevoke(LeaseRevokeRequest request) {
}
}
I think proposal1 is more straightforward, we are constructing a huge client, the code snippet could be very long. Proposal2 divides these services to different sub-client, and we can implement services step by step. so what do you think?
As of now Proposal2 seems to be a good starting point... I was just thinking loudly that how big would it be to change from proposal 2 to proposal 1 later.
I think you earlier mentioned to wrap up the kv impl first, so proposal2 sounds good. What say?
@raoofm as of now, etcd v3 has six kind of services: KV, Watch, Lease, Cluster, Maintenance, Auth, at the very beginning, we may just implement KV, Watch, Lease services, for proposal2, we separate different services to different sub-client, as we add more service implementation, we add more sub-clients, I am not even going to combine all these sub-clients to one huge client at last. We can keep this. wdyt?