commons-dev mailing list archives

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

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

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

> 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:

http://cvs.apache.org/viewcvs.cgi/incubator/directory/snickers/trunk/codec-s
tateful/src/java/org/apache/commons/codec/stateful/DecoderStack.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/DecoderStackTest.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.

> > 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.

+1

> 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.

+1

<snip/>

> 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 :).

Alex



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


Mime
View raw message