jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Observation design (Was: svn commit: r1351414 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak: api/ChangeSet.java api/ContentSession.java core/ContentSessionImpl.java)
Date Mon, 18 Jun 2012 17:00:33 GMT
Hi,

Nice work pushing this ahead! Some design comments below.

On Mon, Jun 18, 2012 at 9:48 AM,  <mduerig@apache.org> 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

Mime
View raw message