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. BR, Jukka Zitting
