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 Fri, 09 Mar 2012 19:15:05 GMT
On Fri, Mar 9, 2012 at 2:12 PM, sebb <sebbaz@gmail.com> wrote:

> On 9 March 2012 19:02, Gary Gregory <garydgregory@gmail.com> wrote:
> > Ok, so now, it look like the next release will be 1.7 and not 1.6.1
> because
> > of the addition of new Nysiis codec.
>
> +1, it's significant new code.
>
> > Would [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>] be
> OK
> > in 1.7 or should it be for a 2.0?
>
> Depends on how it's implemented - does it change the behaviour for
> end-users?
>

If implemented [CODEC-134] throws an exception on garbage input. The
current behavior is garbage-in-garbage-out.

There is an argument for creating a separate "strict" codec...

Gary


>
> > Gary
> >
> > On Thu, Mar 8, 2012 at 11:14 AM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >
> >> 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
> >>
> >
> >
> >
> > --
> > 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
>
>


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