Return-Path: 
 <commons-dev-return-54884-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 63494 invoked from network); 2 Jul 2004 16:18:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 2 Jul 2004 16:18:29 -0000
Received: (qmail 29897 invoked by uid 500); 2 Jul 2004 16:18:33 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 29764 invoked by uid 500); 2 Jul 2004 16:18:32 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 29741 invoked by uid 99); 2 Jul 2004 16:18:32 -0000
X-ASF-Spam-Status: No, hits=0.7 required=10.0
	tests=FROM_ENDS_IN_NUMS,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received: from [205.152.59.71] (HELO imf23aec.mail.bellsouth.net)
 (205.152.59.71)
  by apache.org (qpsmtpd/0.27.1) with ESMTP; Fri, 02 Jul 2004 09:18:30 -0700
Received: from [172.16.1.8] ([68.218.232.170])
          by imf23aec.mail.bellsouth.net
          (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP
          id
 <20040702161816.WAVE1779.imf23aec.mail.bellsouth.net@[172.16.1.8]>;
          Fri, 2 Jul 2004 12:18:16 -0400
Subject: [codec] Stateful/Streaming/Chunking Codecs (was: Who's In Charge)
From: Alex Karasulu <aok123@bellsouth.net>
To: mark_diggory@harvard.edu
Cc: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <40E583EA.3040306@latte.harvard.edu>
References: <2B64219028BBFF48B3CC957EF10B58FE03ECC1@ns1018.SSSI.seagull.nl>
	 <40E47D9C.6080603@unicon.net>
	 <1088776497.15862.7.camel@fermi.trunk.joshua-tree.org>
	 <40E575F0.1050903@latte.harvard.edu>
	 <1088781555.16055.30.camel@fermi.trunk.joshua-tree.org>
	 <1088781935.16055.36.camel@fermi.trunk.joshua-tree.org>
	 <40E583EA.3040306@latte.harvard.edu>
Content-Type: text/plain
Message-Id: <1088785247.16151.26.camel@fermi.trunk.joshua-tree.org>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Fri, 02 Jul 2004 12:20:48 -0400
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

<snip/>

> When I think about this, I come back to the Architecture used for the 
> JAXP Transformer Source and Result objects.

Is there some documentation on this architecture out there?  Might be
good for me to look it over.  BTW, although not directly related to JAXP
architecture specifically we looked at SAX while opting to go with the
callback mechanism.  The DecoderCallback is analogous to the SAX
handler.

> so in StatefulDecoder you have
> 
> void decode( Object encoded ) throws DecoderException ;
> 
> 
> What about something like:
> 
> void decode( EncodedSource source ) throws DecoderException ;
> 
> 
> then you can have
> 
> ByteBufferSource implements EncodedSource { ...
> 
> and
> 
> ByteArraySource impements EncodedSource { ...

I like this approach.  What would the EncodedSource interface look like
or is it just a marker interface?

> The Source Implementations are responsible for those aspects that make 
> them NIO or not, then the Decoder itself stays generic and can even be 
> reused across different Source Implementations (Similar to how JAXP can 
> have a DOMSource, StreamSource or SAXSource).

That's most excellent; this is the goal we are all trying to achieve. 
The use of EncodedSource makes the API more explicit in the fact that it
operates upon some 'encoded' substrate btw.  It will give the API a
better defined symetry when we confront the Encoder interfaces.

If you'll permit me to play devil's advocate, let me ask what difference
is there in casting a EncodedSource to a
ByteArraySource/ByteBufferSource from casting an Object to a
byte[]/ByteBuffer?  In either case the API user will still have to cast
a general interface to get at a more specific implementation. 
Furthermore an extra wrapper object implementing EncodedSource would
need to be defined and instantiated in order to carry the byte[] or
ByteBuffer: referring here to the ByteArraySource and ByteBufferSource
implemenations respectfully.

Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org