Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 76285 invoked from network); 17 Nov 2005 13:43:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Nov 2005 13:43:26 -0000 Received: (qmail 97887 invoked by uid 500); 17 Nov 2005 13:43:25 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 97845 invoked by uid 500); 17 Nov 2005 13:43:24 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 97834 invoked by uid 99); 17 Nov 2005 13:43:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 05:43:24 -0800 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [217.79.216.190] (HELO rly06e.srv.mailcontrol.com) (217.79.216.190) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 05:44:58 -0800 Received: from c1-ex001.groupinfra.com ([213.86.115.108]) by rly06e.srv.mailcontrol.com (MailControl) with ESMTP id jAHDgl1x022997 for ; Thu, 17 Nov 2005 13:43:01 GMT Received: from uk-ex004.groupinfra.com ([158.234.68.230]) by c1-ex001.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 13:43:00 +0000 Received: from uk-ex001.groupinfra.com ([158.234.68.229]) by uk-ex004.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 13:43:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EB7C.D353B20B" Subject: RE: [jira] Commented: (DIRMINA-121) Per-port filter chain Date: Thu, 17 Nov 2005 13:43:00 -0000 Message-ID: <75CFC296F70A08409390004F30EF9B850696841F@uk-ex001.groupinfra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [jira] Commented: (DIRMINA-121) Per-port filter chain Thread-Index: AcXre6Q5eGp0BLhPRtSzqXeYsKIJ8gAACj+A From: "Irving, Dave" To: "Apache Directory Developers List" X-OriginalArrivalTime: 17 Nov 2005 13:43:00.0183 (UTC) FILETIME=[D3347670:01C5EB7C] X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.69.0.116 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB7C.D353B20B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > I thought IoFilter.init(IoFilterchain, NextFilter, IoSession) makes sense instead. Am I missing something? :)=20 =20 The only problem here is that it implies that the filter always has a session after it has been init'ed. For shared filters this may not be the case (for example, a port filter would be init'ed at first use, but that doesn't mean it'll always have any sessions to talk to). =20 Keeping IoSession out of init (IMHO) steers implementors towards using init / destroy for per-filter initialisation (such as obtaining resources). A filter which wants to kick out events when a session is created can use sessionCreated for this. Filters would never be inited until a session comes along. My proposal does have a problem though: A shared (acceptor / port)=20 filter would only be inited / destroyed once (not per session) because it's the NextFilter that contains the smarts (not the filter). It means that per session init / destroy logic should come in "sessionCreated" / "sessionDestroyed" and not "init".=20 "init" / "destroy" would be used for initialisation / tear-down of the filter itself (e.g. acquiring / releasing resources). > I think we should delay calling init() or destroy() when it is added to per-manager or per-port chain at the moment to when it is copied to per-session chain.=20=20=20 > So we can think per-manager or per-port chain is just an *inactive* chain that provides data structure only.=20=20=20 > And I don't see any reason to call init() in manager/port level if it works only for session.=20 =20 What about per filter initialisation?=20 I was thinking that a filter would be inited the first time it was employed (i.e, first session for acceptor filters, first session on port for port filters, and per session for session filters). =20 Dave =20 WDYT? Trustin --=20 what we call human nature is actually human habit -- http://gleamynode.net/=20 This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It may contain proprietary material, confidential information = and/or be subject to legal privilege. It should not be copied, disclosed to= , retained or used by, any other party. If you are not an intended recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you. ------_=_NextPart_001_01C5EB7C.D353B20B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 >  I thought=20 IoFilter.init(IoFilterchain, NextFilter, IoSession) makes sense instead.&nb= sp;=20 Am I missing something? :) 
 
The only problem here is that it implies that the = filter=20 always has a session after it has been init'ed.
For shared filters this may not be the case (for e= xample, a=20 port filter would be init'ed at first use, but that doesn't mean=20 it'll always have any sessions to talk to).
 
Keeping IoSession out of init (IMHO) steers implem= entors=20 towards using init / destroy for per-filter initialisation (such a= s=20 obtaining resources).
A filter which wants to kick out events when a ses= sion is=20 created can use sessionCreated for this.

Filters=20 would never be inited until a session comes along.
My proposal does ha= ve a=20 problem though: A shared (acceptor / port)
filter would only be inite= d /=20 destroyed once (not per session) because
it's the NextFilter that cont= ains=20 the smarts (not the filter).
It means that per session init / destroy = logic=20 should come in
"sessionCreated" / "sessionDestroyed" and not "init".= =20
"init" / "destroy" would be used for initialisation / tear-down of=20 the
filter itself (e.g. acquiring / releasing resources).

 >  I think we should delay calling ini= t() or=20 destroy() when it is added to per-manager or per-port chain at the moment t= o=20 when it is copied to per-session chain.   
>=20  So we can think per-manager or per-port chain is just a= n=20 *inactive* chain that provides data structure only.   
>=20  And I don't see any reason to call init() in manager/po= rt=20 level if it works only for session. 
 
What=20 about per filter initialisation? 
I was=20 thinking that a filter would be inited the first time it was employed = (i.e,=20 first session for acceptor filters, first session on port  for port filters, and per session for= session=20 filters).
 
Dave
 

WDYT?

Trustin
-- what=20 we call human nature is actually human habit
--
http://gleamynode.net/

This e-mail and= any attachment is for authorised use by the intended recipient(s) only. It= may contain proprietary material, confidential information and/or be subje= ct to legal privilege. It should not be copied, disclosed to, retained or u= sed by, any other party. If you are not an intended recipient then please p= romptly delete this e-mail and any attachment and all copies and inform the= sender. Thank you.

------_=_NextPart_001_01C5EB7C.D353B20B--