I agree that a mechanism to cope with children is needed, other than filtering by name.
I partially agree when you say that the end result of a single operation can be either successful, skipped or failed. I am not really sure if we need the skipped result, because a set of operations is supposed to be built on top of an immutable state of the repository. A user reads revision X, applies some operations on the tree at revision X, and submits the operations to the server. In this case, a delete operation on a non-existing node is not tolerable from the client. On the other hand, a skipped result makes sense if we expect clients that want to build a set of operations on a revision X and apply that set of operations on a revision Y, with X older than Y. In this case, we have to respect the "intent" of the operation: the removal of a non-existent node should succeed. In this last case, though, I better prefer the branch/commit/merge approach of the Microkernel, which works with non-skippable, exact operations and makes the difference clear between errors caused by malformed operations and errors caused by conflicting state. 2015-02-02 14:36 GMT+01:00 Michael Dürig <[email protected]>: > > Hi, > > I finally found some time to read your draft: > > * what about large number of child nodes? I think we need some kind of > support for paging/chunking to avoid reading millions of children in one go. > > * the write operations all fail if the operation "has been done already": > E.g. the remove operation fails if there isn't any node at the given path. > However, in many cases this is not interesting because the intention is to > make sure the node is gone. To prevent extra round trips, I suggest to > provide a way for callers to distinguish a failed operation from this case. > Same goes for adding items where the same items has already been added. See > http://markmail.org/message/flst4eiqvbp4gi3z for a related discussion where > this has come up within Oak's user management. > > Michael > > On 23.1.15 6:09 , Francesco Mari wrote: >> >> Hi all, >> >> since I don't have access to the wiki, I started to write down a draft >> for the remote API in a public GitHub repository [1]. >> >> I didn't write much so far, but I invite every interested party to >> take a look at it for suggestions and improvements. >> >> Thanks, >> >> Francesco >> >> [1]: https://github.com/francescomari/oak-remote >> >
