From directory-dev-return-3628-apmail-incubator-directory-dev-archive=incubator.apache.org@incubator.apache.org Fri Jan 07 04:49:51 2005 Return-Path: Delivered-To: apmail-incubator-directory-dev-archive@www.apache.org Received: (qmail 33746 invoked from network); 7 Jan 2005 04:49:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 7 Jan 2005 04:49:51 -0000 Received: (qmail 86966 invoked by uid 500); 7 Jan 2005 04:49:51 -0000 Delivered-To: apmail-incubator-directory-dev-archive@incubator.apache.org Received: (qmail 86930 invoked by uid 500); 7 Jan 2005 04:49:50 -0000 Mailing-List: contact directory-dev-help@incubator.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 directory-dev@incubator.apache.org Received: (qmail 86916 invoked by uid 99); 7 Jan 2005 04:49:50 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of trustin@gmail.com designates 64.233.184.199 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.199) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 06 Jan 2005 20:49:48 -0800 Received: by wproxy.gmail.com with SMTP id 58so7253wri for ; Thu, 06 Jan 2005 20:49:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=jvqubwI4r8oJQJ7FlfcXVnTJScns9Zig1wiZSy/+HTg61I0y2ArhuK+RPwH+z84Gpc9zdvqpE/EkV3IfB/HQGfi5uVmGq0Slj0Mv0wdANuuZCINh93iGWAr/WIVj9ssUQ+jMwQh7cbNb+uzHBU+VBNGUuu/y6HwUY45fThk4IRg= Received: by 10.54.25.66 with SMTP id 66mr471004wry; Thu, 06 Jan 2005 20:49:45 -0800 (PST) Received: by 10.54.21.48 with HTTP; Thu, 6 Jan 2005 20:49:45 -0800 (PST) Message-ID: <768dcb2e050106204921f7abd9@mail.gmail.com> Date: Fri, 7 Jan 2005 13:49:45 +0900 From: Trustin Lee Reply-To: Trustin Lee To: Apache Directory Developers List , akarasulu@locus.apache.org Subject: Re: Re: [asn1] Stateful Decoder question. In-Reply-To: <20050105222400.HRBM2073.imf19aec.mail.bellsouth.net@mail.bellsouth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050105222400.HRBM2073.imf19aec.mail.bellsouth.net@mail.bellsouth.net> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi. Long time no see! I'm so busy these days because I have to hand over my works to my co-workers. > > It does seem confusing at first, I guess, but I kinda like it. It's a > > simple way of communicating to the caller that something has happened > > and it needs to do something. Another way to do it would be to have the > > caller and the callee share a queue and when the callee needs to send a > > message to the caller it enqueues it. Then, the caller can either > > I would really like to see what Trustin and Berin think about this as well or if > they have other approaches they can recommend. Callback approach is good. I used it in MINA, too. But I specified callback as a parameter. I think callback should not change once set to avoid confusion. MINA codecs also passes ProtocolSession as a parameter to interact with session handlers. But this approach doesn't fit to pure codec APIs. So I implemented wrapper for ASN1 codec-stateful package. Users can control both the state of codec and session in MINA codec. Current minimal stateful-codec API is fine and users would be able to implement additional methods such as 'setCurrentSocket()' and control it later if they don't use MINA or SedaNG in particular. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/