Hi,
On Wed, Feb 27, 2013 at 2:38 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Indeed. Here's my initial draft of what this could look like:
Committed the first version of this Editor mechanism in revision
1453738. See OAK-673 for further progress.
BR,
Jukka Zitting
On 15.2.13 9:27, Jukka Zitting wrote:
Hi,
On Fri, Feb 15, 2013 at 11:20 AM, Tommaso Teofili teof...@adobe.com wrote:
maybe it would be nice to explicitly design the synchronous / asynchronous
execution of an hook
An Observer is essentially an asynchronous hook.
Right but it might make
On 27/feb/2013, at 10:25, Michael Dürig wrote:
On 15.2.13 9:27, Jukka Zitting wrote:
Hi,
On Fri, Feb 15, 2013 at 11:20 AM, Tommaso Teofili teof...@adobe.com wrote:
maybe it would be nice to explicitly design the synchronous / asynchronous
execution of an hook
An Observer is
Hi,
On Wed, Feb 27, 2013 at 11:25 AM, Michael Dürig mdue...@apache.org wrote:
Right but it might make sense to factor out an API based on these hooks that
frees index implementations of having to worry which hook to use.
Indeed. Here's my initial draft of what this could look like:
On 15/feb/2013, at 08:11, Jukka Zitting wrote:
Hi,
On Thu, Feb 14, 2013 at 10:29 PM, Michael Dürig mdue...@apache.org wrote:
However, there is a difference depending on whether the index is stored in
content or external. For the former case using commit hooks is the right
thing to do. In
Hi,
On Fri, Feb 15, 2013 at 11:20 AM, Tommaso Teofili teof...@adobe.com wrote:
maybe it would be nice to explicitly design the synchronous / asynchronous
execution of an hook
An Observer is essentially an asynchronous hook.
BR,
Jukka Zitting
Hi,
To update the external index: the hooks could be used to remember what
content may needs to be indexed. That is:
(A) The index hook stores the path of the added/removed/changed nodes
(only for those nodes that contain indexed data) in a separate
'toBeIndexed' node, in the form of a tree.
Hi,
On Fri, Feb 15, 2013 at 12:05 PM, Thomas Mueller muel...@adobe.com wrote:
(A) The index hook stores the path of the added/removed/changed nodes
(only for those nodes that contain indexed data) in a separate
'toBeIndexed' node, in the form of a tree.
This information is already available
Hi,
AFAIK indexing currently uses commit hooks for keeping the index up to
date when content changes. As Jukka mentioned this might not be the
right thing to do since when a commit fails, we end up with invalid
index entries. The conclusion was, that indexing should use the
Observer, which
