Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 68741 invoked from network); 1 Nov 2007 16:00:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Nov 2007 16:00:50 -0000 Received: (qmail 92854 invoked by uid 500); 1 Nov 2007 15:32:16 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 92826 invoked by uid 500); 1 Nov 2007 15:32:16 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 92817 invoked by uid 99); 1 Nov 2007 15:32:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 08:32:16 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 01 Nov 2007 15:32:36 +0000 Received: (qmail invoked by alias); 01 Nov 2007 15:31:57 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 01 Nov 2007 16:31:57 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18wF5E78OUwJ7pIfdnsVJowCd3fEr96QCFA3haW/1 aGME9lVW6iirYI Message-ID: <4729F16C.3040905@gmx.de> Date: Thu, 01 Nov 2007 16:31:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: SPI observation: EventFilter lifecycle Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org 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 EventFilter array being null. These changes will allow the SPI implementation to early filter internal events, even before getEvents() gets called. 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. Best regards, Julian