> On 26 Jan 2015, at 15:13, Francesco Mari <[email protected]> wrote: > > What you are proposing is a REST interface where every node can be > treated as an individual resource. This will not work. To fully > leverage the MVCC architecture of Oak, a set of related GET, POST, PUT > and DELETE requests must belong to the same context. This context, in > Oak, is represented by a ContentSession. To express the fact that two > or more requests belong to the same ContentSession, the API must > provide the following functionalities: > > 1. Open a session. This returns a session ID that must be saved by the client. > > 2. Require a valid session ID on every following POST, PUT, DELETE and > GET method. > > 3. Commit or discard a session. This also require a session ID, obviously. > > This solution forces the server to maintain ContentSession instances. > When a client opens a session on an instance of the server, it is > bound to that server instance until the ContentSession is committed or > discarded. This approach enforces a really strict constraint on the > horizontal scalability of the server. > > We can still provide a REST API, but to avoid this constraint we have > to make the API a little bit more coarse grained. In this case we have > to work with trees, and not with single nodes (technically speaking, a > node is a tree with depth zero, but let's ignore it for the sake of > the explanation). > > The root of the repository is the root of the tree we are working on. > Every tree in the repository (the root or any sub-tree of the root) > supports a GET method that allows reading that tree, optionally > filtering out properties and children and enforcing the maximum depth > to read. The root of the repository is a special tree that also > supports a PATCH method. This method allows the client to specify a > set of operations to make the tree move from one valid state to > another valid state. The PATCH operation is not bound to any session, > is atomic and can be performed by any instance of the server. > > This is my analysis so far. I am open to any solution that would > combine these qualities: > > 1. makes effective use of the MVCC approach of Oak. > > 2. is complaint to the REST architecture. > > 3. enables horizontal scalability by eliminating state on the server.
I think it would be good to still provide a clean REST API, just because some use cases can indeed be covered this way and it will keep things simple. Under the hood Oak supports cheap branching, so another option would be to move the “session” management to the client by simply allowing them to fork the content, issue the changes and then finalize things by sending a merge. Again this can work well for many use cases but not all. Finally yes we also will want a way to batch such changes into a single request, since round trips do matter of course. One of the tricky aspects however we learned that using the old Jackrabbit 2.x remoting API is that it can become hard to predict when a change set becomes too big to still be reasonably be processed via the remoting API in one batch. regards, Lukas Kahwe Smith [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
