On 18.6.12 18:00, Jukka Zitting wrote:
Hi,
Nice work pushing this ahead! Some design comments below.
On Mon, Jun 18, 2012 at 9:48 AM,<[email protected]> wrote:
+ /**
+ * Wait for changes to occur at {@code path} in the underlying repository.
+ * If {@code previous} is not {@code null} returns the {@link ChangeSet}
+ * instance following the one given in {@code previous}.
+ *
+ * @param path path to the subtree to watch for changes
+ * @param previous previous {@code ChangeSet} or {@code null}.
+ * @param timeout the maximum time to wait in milliseconds
+ * @return the next {@code ChangeSet} or {@code null} if a timeout
occurred.
+ */
+ @CheckForNull
+ ChangeSet waitForChanges(String path, ChangeSet previous, long timeout);
I'd rather not introduce a blocking method and a new ChangeSet concept
for this. Instead, could we implement observation by polling the
latest state of the tree (or the journal) and using a tree diff to
deliver JCR-level events?
Ideally I'd make the ObservationManager in oak-jcr simply hook into
Session.refresh() and use a per-session background thread to
periodically trigger a new refresh(). Apart from the diff support we
shouldn't need any extra functionality from Oak API.
Stuff like user data and other event details may need more information
that's available in the default diff. We should look at whether we
really do need all that info, and if we do, what's the best way of
making it available through the Oak API. The cleaner and simpler we
can keep the Oak API the better.
Yes we could do that. However I think the approach I outlined has a
number of advantages which outweigh the additional complexity (which is
minimal btw):
- Observation is made explicit feature wise.
- We can implement the polling approach (using a 0 timeout) but also
have the option to do blocking. Since this can be directly delegated to
the Microkernel (waitForCommit) the added complexity for this is minimal.
- With the polling approach we offload more complexity to the consumer
of the API since one has to decide on a reasonable poll interval which
might be a difficult trade off between latency and server load.
- ChangeSet is just a container carrying the trees as they where after
and before the change. So this is very close to the diffing approach you
describe only a bit more explicit. Also ChangeSet is the place where
additional information like change set meta data could live. I'm close
to certain that we will need something along these lines (i.e. userData,
timestamps, user who initiated that change, session id of the
originating session).
- The approach aligns neatly with the JCR features: implement
observation using blocking calls and implement journalling by using non
blocking calls. Also it aligns neatly with the features of the
Microkernel: waitForCommit and getRevisionHistory.
Michael
BR,
Jukka Zitting
