commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [codec] What version should implement a behavior change?
Date Thu, 08 Mar 2012 16:14:55 GMT
Ok, so where are we on all this and specifically
[CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>
]?

It seems that [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>],
if applied should be for a 1.x, not a 1.x.y because of the change of
behavior.

If it is not applied, then we need... new classes or more behavior in the
current class tunnable with something (constructor, config object)

We also need someone to implement it...

Thoughts?

Gary

On Tue, Mar 6, 2012 at 10:35 PM, Julius Davies <juliusdavies@gmail.com>wrote:

> Maybe time to add a Base64(int mode) constructor!   Yay, room for 32
> true/false bitwise fields!
>
> Sorry I can't respond inline to the email like a normal person.   Bad
> habit.
>
> yours,
>
> Julius
>
> On Tue, Mar 6, 2012 at 11:40 AM, sebb <sebbaz@gmail.com> wrote:
> > On 6 March 2012 19:33, Gary Gregory <garydgregory@gmail.com> wrote:
> >> What about passing in a "boolean strict" to the constructor of the
> codecs?
> >
> > What does strict mean? See my comment:
> >
> > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
> >
> > If we do add another parameter (which is not popular with others), at
> > least let's make sure it's the last one we need to add.
> >
> >> Gary
> >>
> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <juliusdavies@gmail.com
> >wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> CODEC-95 talked about these issues, too (in this case with Base64).
> >>>
> >>> https://issues.apache.org/jira/browse/CODEC-95
> >>>
> >>>
> >>> Personally, I would prefer to see some new "strict" classes defined,
> >>> and to preserve the garbage-in/garbage-out behaviour on the current
> >>> existing classes.
> >>>
> >>>
> >>> Here are the new classes I would like to see:
> >>>
> >>>
> >>> Base32Strict
> >>> Base32StrictInputStream
> >>> Base32StrictOutputStream
> >>> Base64Strict
> >>> Base64StrictInputStream
> >>> Base64StrictOutputStream
> >>>
> >>>
> >>> At the same time it does make the API a bit more intimidating and
> >>> harder to learn, but I think striving for drop-in
> >>> reverse-compatibility of the existing classes is desirable.
> >>>
> >>>
> >>> yours,
> >>>
> >>> Julius
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <garydgregory@gmail.com>
> >>> wrote:
> >>> > Hello All,
> >>> >
> >>> > We have a patch for
> >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
> >>> > but it is a change in behavior. In order to avoid a potential nasty
> >>> > surprise for call sites, we need to decide when something like this
> can
> >>> be
> >>> > done.
> >>> >
> >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
> >>> patch,
> >>> > you get an exception.
> >>> >
> >>> > 1) Is the proposed patch acceptable in the sense that we do not whant
> >>> GIGO?
> >>> > Should there instead be a validate method for example?
> >>> >
> >>> > 2) What kind of version is this change in behavior acceptable?
> >>> Maintenance
> >>> > (1.6.1), Minor (1.7) or Major (2.0)?
> >>> >
> >>> > Thank you,
> >>> > Gary
> >>> >
> >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string
> into
> >>> > arbitrary value
> >>> >
> >>> > --
> >>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >>> > Spring Batch in Action: <http://s.apache.org/HOq>
> http://bit.ly/bqpbCK
> >>> > Blog: http://garygregory.wordpress.com
> >>> > Home: http://garygregory.com/
> >>> > Tweet! http://twitter.com/GaryGregory
> >>>
> >>>
> >>>
> >>> --
> >>> yours,
> >>>
> >>> Julius Davies
> >>> 604-222-3310 (Home)
> >>>
> >>> $ sudo apt-get install cowsay
> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> >>> http://juliusdavies.ca/cowsay/
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> yours,
>
> Julius Davies
> 604-222-3310 (Home)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message