Marcel Reutegger wrote:
...
I'm working on a proposal that introduces a Subscription interface to
the SPI, which should solve the above issue.
here's a sneak preview:
http://people.apache.org/~mreutegg/spi-event/proposal.png
...
OK, as far as I understand this, we pass a Subscription obje
Marcel Reutegger wrote:
Julian Reschke wrote:
Question: do we expect many cases in which a client stops listening
for events, but keeps the JCR session open? In this case it might be
good if we could indicate that an EventFilter is not going to be used
anymore, for instance using a dispose() m
Julian Reschke wrote:
Question: do we expect many cases in which a client stops listening for
events, but keeps the JCR session open? In this case it might be good if
we could indicate that an EventFilter is not going to be used anymore,
for instance using a dispose() method.
this is actually
Jukka Zitting wrote:
Hi,
On 11/1/07, Julian Reschke <[EMAIL PROTECTED]> wrote:
Proposal: document that getEvents only needs to accept EventFilter
objects created by the same SPI implementation for the same SessionInfo
(this reflects reality in JCR2SPI)
+1 There's no guarantee that a remote im
Hi,
On 11/1/07, Julian Reschke <[EMAIL PROTECTED]> wrote:
> Proposal: document that getEvents only needs to accept EventFilter
> objects created by the same SPI implementation for the same SessionInfo
> (this reflects reality in JCR2SPI)
+1 There's no guarantee that a remote implementation can de
Hi,
here are some thoughts about the current SPI EventFilter interface:
Proposal: document that getEvents only needs to accept EventFilter
objects created by the same SPI implementation for the same SessionInfo
(this reflects reality in JCR2SPI)
Proposal: remove special case in getEvents for
