Re: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now!

-- Galder Zamarreño Infinispan, Red Hat I think the README I've produce is a bit confusing, I'll work to improve for future versions. In the mean time, let me explain this: The reason Promises are used instead of callback parameters is precisely to avoid this kind of deep nesting. The code below shows 4 (but could be N really) operations which are chained only 2 levels deep: connected.then(function(client) { ... <- Do something with the client var putCall = client.put('key', 'value'); var getCall = putCall.then(function() { return client.get('key'); }); var containsKeyCall = getCall.then(function() { return client.containsKey('key'); }); var removeCall = containsKeyCall.then(function(contains) { return client.remove('key'); }) }); The key aspect of this is that no matter how many operations you want to chain together, the nesting levels are constant. You could have 100 operations chained together, you would still only have 2 levels deep. The README file might not make this so obvious and hence I'll work to improve on that. Also, the API above is using Promise API which will be standard in ES6. Even though Infinispan JS Client is based on ES5, the `promise` module sticks to the forthcoming standard Promise API, and hence we're using something that in a few years will be standard, which is a good thing. Conceptually, Promise API is similar to Scala's Future or Java's CompletableFuture. The other alternative that's used in Node.js is passing callbacks as parameters to each put/get call... and that does cause very deep nesting, because if you want to chain 100 operations together, you need 100 nested calls! Plus not centralised error handling, and many other disadvantages. Independent of the correctness of the syntax, this API can be split in several concepts: 1. The first one is that for those operations that have not a return, e.g. a put, you're passing on the client instance. I think that sounds fine. 2. For your API to work, get() would need to return something other than Promise that has a use/save methods. I'm very reluctant to do anything like that since it's not standard and would require more upfront understanding from the user. Right now, we provide a Promise, a concept that's very well understood in the JS community and that will become standard in ES6.