Hi, >>> Š oak-http are the >> > only complex direct Java clients of the Oak API >> >> I thought Oak HTTP basically _is_ (very closely matches) the Oak API. > > >That's why I qualified it with "to a lesser degree", which you didn't >include in your quote above.
I guess this is an example where a direct discussion would be more efficient than an email... I don't want to split a hair, but "to a lesser degree complex" doesn't sound like "basically is" :-) >>On the other hand, we seem to have features (for example the transient >> space) that were originally planned for the client now implemented in >>Oak >> Core or even Oak MK (branch / merge). We should really discuss this. >> >> See the list archives from around March and April for extensive >discussions about how the changelog of a transient space is best >represented. >The big point that people keep missing here is that we *need* >a way to represent uncommitted changes inside oak-core, as otherwise >things >like node type validation or other commit hooks are impossible. A remoting >client can and should still batch the transient space on the client side, >the API design explicitly allows that. I see all layers need a way to represent uncommitted changes, even oak-mk need keep things uncommitted for the duration of the commit method, but ideally such a mechanism should be internal to each layer, so that method calls that cross the layer boundaries are minimized. Looking at method call traces I see now that in fact a JCR "Node.addNode" call doesn't always result in a corresponding call in the MicroKernel, so I guess my concern about the transient space might not be justified when it comes to calls to the MicroKernel (even thought there are still quite a lot of MicroKernel calls, and quite unexpected calls, for relatively simple JCR operations). As for calls between Oak JCR and Oak Core I can't comment. Regards, Thomas
