commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject RE: [codec] StatefulDecoders
Date Wed, 24 Mar 2004 01:23:00 GMT

Ok let's take a breath and dive into this email :-).

> -----Original Message-----
> From: Brett Henderson []

> Perhaps our two approaches are closer in design than you suspect.  I'll
> talk
> about ByteProducer and ByteConsumer from my implementation to illustrate
> this.  These interfaces are used to pass events of type "byte[]".  A
> ByteConsumer is attached to a ByteProducer and receives all data generated
> by the ByteProducer implementation (eg. Base64Encoder).  The "events" are
> of
> type byte[].  ByteConsumer is the callback object for ByteProducer.

I don't think the two approaches are all that different.  You're scheme uses
explicit types taking away the freedom to change the type of decoded
substrate.  Its much more type safe however.

> Your two major interfaces are StatefulDecoder and DecoderCallback.
> StatefulDecoder is the equivalent of the combination of ByteProducer and
> ByteConsumer (ie. ByteByteEngine).  DecoderCallback is the equivalent of
> ByteConsumer only.

Right I agree.

> The major difference I see is that I have separated the input interface
> from
> the output interface.  The eliminates the need for the callback interface
> because the callback interface is simply the input interface.  I believe
> this is a simpler and more flexible approach because there is no
> distinction
> between encoders/decoders and callback objects, an encoder/decoder can act
> as the callback object for another encoder/decoder if necessary.
> Producers/consumers provide all the benefits of callbacks and have other
> additional benefits.
> The second difference is that I have created specific producers/consumers
> for each data type.  If strong typing is not desired, these specific
> interfaces could be removed and Producer would always produce data of type
> Object and Consumer would always receive data of type Object.  This would
> reduce the complexity of my implementation to the same as yours.

Yes I see that.

> Pipelining (for serial pipelines) does not add complexity to my
> implementation.  However it is directly supported because each stage can
> act
> as the callback object for the previous stage allowing stages to directly
> communicate.  This is very simple and allows great flexibility in creating
> encoding chains/pipelines.

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:

And go on to show how it's used like in this test code here:

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.

> > I'm viewing decoders to be simple event generators based on encoding
> > structure and modeling the callback as such events.  This way the 
> > decoder does what it does minimally leaving any higher level content
> > interpretation up to other facilities built on top.
> Yep, this is a good approach, each decoder should not be concerned with
> anything other than implementing an algorithm.


> As I've stated above, stages do not need to add complexity to the design,
> they are simply a result of allowing input and output interfaces to
> communicate.

Makes perfect sense it's just another way of looking at the same thing.

> You're right, encoders and decoders are special types of filters.  But why
> create a distinction between the two when there is no reason to.  If
> encoders require different methods to decoders then by all means create
> separate interfaces, but they are doing the same thing (transforming data)
> so surely we can use the same interfaces for both purposes.

What do others think about this?  It sounds sensible but I can't seem
to shake the sense of comfort in making the distinction between the two.
For the stateless operation there we may not have symmetry between the
decode and encode halves.

> Some of the concepts and terminology between codec and an event based
> server
> are similar.  In codec our "events" are data being generated by an
> algorithm, in SEDA events are more generic messages being passed between
> components of a server.  However the goals of the two are very different,
> codec cares about efficient transformation of data and SEDA cares about
> enabling highly concurrent processing with huge loads.
> I don't believe adding a producer/consumer concept to codec means we're
> confusing the boundaries between the two systems simply because they both
> use the terms producer and consumer.



> The wrapper class will be necessary regardless of whether you're using a
> producer/consumer approach or callbacks.  I may have been confusing with
> my
> above statements but the purpose of the wrapper class is to allow a client
> to use the library without caring about callbacks, events, etc when the
> size
> of their data is small.
> For example, I have an array of data and I want to base64 encode it.  I
> want
> to be able to use an encoder without catching events or processed data, I
> just want to call a method passing a byte[] argument and receive a byte[]
> result.  That is what the wrapper class provides.

I see that.

> > Let's then start another SEDA trail and see if we can both
> > work together
> >
> > to create a simple SEDA API.  Are you up for that?
> >
> Yeah, I'm interested.  I have a fair bit on at the moment but will see how
> I
> go.

Whheww!  We never did start that SEDA trail and it was probably better off
for the mail server :).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message