commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [codec] Moving on to codec 2.0
Date Wed, 30 Mar 2011 17:04:48 GMT
On 30 March 2011 16:19, Jochen Wiedmann <jochen.wiedmann@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 8:52 PM, sebb <sebbaz@gmail.com> wrote:
>
>> I think that should be avoided unless the API is also being changed in
>> an incompatible way, and then only if it really is impossible to
>> maintain backwards compatibility.
>
> I think there are excellent reasons to change the API in codec.
> Reasons include lack of support for streaming in most cases, lack of
> support for integration in SAX or StAX streams and the like, which
> could be relatively easy with standard interfaces. Take, for example,
>
>    http://www.jarvana.com/jarvana/view/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2-javadoc.jar!/org/apache/ws/commons/util/Base64.html
>

But does the API have to change, or could these additional features be
supported by adding new methods and classes?

For example, I originally thought that the fixes to Net NNTP to
support long article Ids would require a compatibilty break, as ints
were used throughout, but having done the work it turned out that
compatibility could be maintained by adding one or two new classes,
and some new methods. Users wanting to use the new methods will of
course have to edit and recompile, but other Net users won't be
affected.

>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message