RE: [codec] StatefulDecoders

[Brett Henderson <ja...@bretth.com>]

Alex,

Sorry about the delay.  I'm a bit snowed under at the moment.

I've attached producers/consumers that process Object instances instead of
type specific data.

Some differences between these interfaces and those you've already built
are:
1. These have no monitor facility.  All errors result in a CodecException
being thrown.  There is no concept of a warning.
2. These have a finalize concept which is required for implementations such
as base64 where padding on the final data block is required.
3. These have flush methods to allow the chain to be flushed without being
finalized.
4. These have a propogating flag which allows finalize/flush calls to be
propagated through codec chains.  By default this is true but can be set to
false.  This is necessary when a single consumer (eg. OutputStreamConsumer)
receives streams from multiple sources and each of those sources are
finalized before the next is started.  In this case you don't want the
OutputStreamConsumer to be finalized (and the underlying stream closed)
multiple times, you want this to occur only after the final input source
completes.  Hope this makes sense.

With regards to each difference:
1. Not sure of the correct approach here.  I threw exceptions because it was
simpler to implement and made it harder to end up with silent errors
occurring.  A monitor approach is more flexible although perhaps harder to
use from a client perspective.
2. I believe you will need to add a finalize concept.  Some codecs require
notification that this is the final processing call (ie. Base64).
3. Flush isn't critical.  I just added it for completeness.
4. A propagating option isn't critical and java IOStreams don't have this
concept.  However a common problem is where you wish to feed the result of
several streams into a single stream without the close on each top level
stream calling close on the receiving stream.  Another way of overcoming
this is to create a special Noop Nopropagate codec that you insert into the
chain to prevent these calls propagating.

I meant to create some sample code using my interfaces to compare with yours
but I can't get it done at the moment.

You're obviously clued in on what's required, any differences between mine
and yours is relatively small and I'm sure either would suit the purposes of
codec.

Given that I'm taking way too long to do anything at the moment I'll leave
it in your capable hands.  My current work should ease up in a few weeks and
I'll try to give you a hand again then.

Cheers,
Brett

> Could you give some example's of how this would look just using
> 
> Objects instead of specific types to implement what the DecoderStack
> 
> does here:
> 
> 
> 
> http://cvs.apache.org/viewcvs.cgi/incubator/directory/snickers
> /trunk/codec-s
> 
> tateful/src/java/org/apache/commons/codec/stateful/DecoderStac
> k.java?rev=972
> 
> 4&root=Apache-SVN&view=auto
> 
> 
> 
> And go on to show how it's used like in this test code here:
> 
> 
> 
> http://cvs.apache.org/viewcvs.cgi/incubator/directory/snickers
> /trunk/codec-s
> 
> tateful/src/test/org/apache/commons/codec/stateful/DecoderStac
> kTest.java?rev
> 
> =9724&root=Apache-SVN&view=auto
> 
> 
> 
> Specifically I'm referring to the usage of the DecoderStack in the
> 
> testDecode() example which shows the chaining really simply.
> 
> Perhaps looking at the two use cases we can come to a better
> conclusion.
> 
> 
> 
> 
> 
> > Does the above make sense?  If so, please give it careful
> > consideration
> 
> > because I originally used the callback design and modified it to use
> 
> > producers/consumers because I think it is actually simpler
> and is much
> 
> > more
> 
> > flexible.
> 
> 
> 
> Yes it makes sense I just want to see it and play with it.
> Can you whip
> 
> it up and we'll begin getting a feel for both sets of interfaces.
> 
> 
> 
> > If you're still not convinced I guess I'll have to give in
> and go with
> > the
> 
> > flow ;-)
> 
> 
> 
> Nah we'll try come to an understanding.
> 
> 
> 

RE: [codec] StatefulDecoders

[Alex Karasulu <ao...@bellsouth.net>]

> -----Original Message-----
> From: Brett Henderson [mailto:jakarta@bretth.com]

I got it and it looks sensible but let me lull it over a bit and perhaps we
can also get the input of others as well.  Just wanted to let you know in
case you don't here from me for a bit.

Alex



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