> Every functionality added to ZK will make it harder to maintain. The use case
Definitely, but it's hard to debate about features at that level. If we delete the whole code base, we have nothing to maintain, so given this r. > recursiveDelete, recursiveCreate: If you want to create /A/C/D-1 just use > recursiveCreate and you will end up with /A/C/D-1, even if the full parent > path did not exist before. You're missing the actual problem. Recursive create and delete are non-issues per se. They become issues once you want to use the ZK filesystem state for coordination, which is the only advised use case for ZK. Other messages in this thread have already described the problems related to intermediate state visibility, and some techniques to deal with them. The problem is that as the number of dynamic pieces increase, the cost of maintaining all of that logic increases too, and it becomes non-practical. ZK is great at what it does, and these compound atomic operations target real use cases for what it's most useful at. In my view, the additional complexity in the code would not be so great to have this feature, and it would be absolutely nothing if compared to the additional logic which these realistic use cases require to deal with intermediate states. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter
