commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Henderson" <>
Subject RE: [codec] StatefulDecoders
Date Wed, 25 Feb 2004 00:40:33 GMT
> From: Gary Gregory [] 
> I think you are barking up the right tree ;-)
That's cool.  If nothing else, developing it kept me amused for a

> 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. I have not looked at 
> the new enough stuff to make intelligent comments. 
> Unfortunately, I do not have much time right now for this. 

I wouldn't want to deprecate the old because it is functional and
simple to use for the common use cases.

In "my" ideal world I would like to see the following:
1. Introduce an API like the one I have developed allowing for
very flexible conversion pipelines to be created.  People requiring
a high degree of control over the conversion process or requiring a
conversion not currently provided by the existing codec APIs would
use this API.
2. Optionally utilise the low-level API above to implement the
existing codec APIs which cover the common use cases.  Most users
would use this API because it is simpler (less code required) but
at the expense of flexibility.

The fact that I see the two APIs remaining separate suggests that
it is worth considering keeping them as separate projects ...

> Hopefully others will opine.
I suspect that most will agree with your point of view :-)


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

View raw message