Return-Path: Delivered-To: apmail-incubator-directory-dev-archive@www.apache.org Received: (qmail 30237 invoked from network); 24 Feb 2004 01:33:00 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 24 Feb 2004 01:33:00 -0000 Received: (qmail 69928 invoked by uid 500); 24 Feb 2004 01:32:35 -0000 Delivered-To: apmail-incubator-directory-dev-archive@incubator.apache.org Received: (qmail 69827 invoked by uid 500); 24 Feb 2004 01:32:35 -0000 Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Apache Directory Developers List" Reply-To: "Apache Directory Developers List" Delivered-To: mailing list directory-dev@incubator.apache.org Delivered-To: moderator for directory-dev@incubator.apache.org Received: (qmail 66265 invoked from network); 24 Feb 2004 01:29:38 -0000 Message-ID: <245A7290F0E0D311BF6E009027E7908B0934B13C@atlanta.seagullsw.com> From: Gary Gregory To: 'Jakarta Commons Developers List' Cc: 'Apache Directory Developers List' Subject: RE: [codec] StatefulDecoders Date: Mon, 23 Feb 2004 20:29:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA75.8B4D3E5E" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3FA75.8B4D3E5E Content-Type: text/plain Let's split this into two chunks: (1) DecoderException superclass (2) StatefulDecoders Gary > -----Original Message----- > From: Alex Karasulu [mailto:aok123@bellsouth.net] > Sent: Friday, February 20, 2004 23:13 > To: commons-dev@jakarta.apache.org > Cc: 'Apache Directory Developers List' > Subject: [codec] StatefulDecoders > > Hi, > > I've been working on the idea of stateful Decoders designed for use with > non-blocking reads where buffers are read from channels and used by > decoders. As you know you don't always get the complete PDU in a single > channel read and so buffers need to be handled in a decoding session. > > This JIRA issue contains attachments explaining the new interface: > > http://nagoya.apache.org/jira/secure/ViewIssue.jspa?id=13599 > > First I would like to figure out what the codec people think about this > stateful decoder concept and then perhaps we can add the interfaces into > the > > codec for general use. > > Also I'm wondering if we can make the DecoderException and the > EncoderException extend the IOException reather than just Exception. > Most of these operations are IO based and it makes sense to me to have the > Exception derive from IOException. > > Alex > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-dev-help@jakarta.apache.org ------_=_NextPart_001_01C3FA75.8B4D3E5E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [codec] StatefulDecoders

Let's split this into two chunks:

(1) DecoderException superclass
(2) StatefulDecoders

Gary

> -----Original Message-----
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
> Sent: Friday, February 20, 2004 23:13
> To: commons-dev@jakarta.apache.org
> Cc: 'Apache Directory Developers List'
> Subject: [codec] StatefulDecoders
>
> Hi,
>
> I've been working on the idea of stateful = Decoders designed for use with
> non-blocking reads where buffers are read from = channels and used by
> decoders.  As you know you don't always = get the complete PDU in a single
> channel read and so buffers need to be handled = in a decoding session.
>
> This JIRA issue contains attachments explaining = the new interface:
>
> http://nagoya.apache.org/jira/secure/ViewIssue.jspa?id= =3D13599
>
> First I would like to figure out what the codec = people think about this
> stateful decoder concept and then perhaps we = can add the interfaces into
> the
>
> codec for general use.
>
> Also I'm wondering if we can make the = DecoderException and the
> EncoderException extend the IOException reather = than just Exception.
> Most of these operations are IO based and it = makes sense to me to have the
> Exception derive from IOException.
>
> Alex
>
>
>
> = ---------------------------------------------------------------------
> To unsubscribe, e-mail: = commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: = commons-dev-help@jakarta.apache.org

------_=_NextPart_001_01C3FA75.8B4D3E5E--