commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <>
Subject RE: [codec] StatefulDecoders
Date Wed, 25 Feb 2004 18:41:29 GMT

In general, I have long preferred the pipeline/event model to the approach
that Alex had, where it would give data to the codec, and then poll it for
state.  However, I don't see something in your implementation that I think
we want.  We want to be able to have structured content handlers and
customized events depending upon the content handler and the registered
event handlers.  This could be particularly important in a streaming
approach to MIME content.  And I also desperately want a regex in this same

> > It is just quite a bit of work to integrate a new framework
> > into [codec]. I mean do we: (1) Find a way to merge the two,
> > or (2) deprecate the old in favor of the new making sure that
> > all the old features exists in the new.

It would make sense to recast the current in the new, once we decide on the
precise and elegant form of the "new" (I use the term loosely, since the
basic approach dates back for decades), using adapters/wrappers to preserve
the current interface.  Although I haven't looked, I suspect that much of
the current code actually involved in codec operations would move readily.

> 1. Introduce an API like the one I have developed allowing for
>    very flexible conversion pipelines to be created.

Drop the word "conversion".  Conversion is simply one of many possible
operations.  These are pipelines; receiving content on one end, performing
operations, and generating events down a chain.  More than one event could
be generated at any point, and the chain can have multiple paths.

	--- Noel

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

View raw message