[
https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys...
]
David Lloyd commented on ELY-43:
--------------------------------
I think that the benefits of Jason's implementation are on the micro-optimization
scale. If we have to construct byte arrays and copy, we've lost that benefit in
spades.
Mostly I just thought you'd find it interesting. :)
[~jason.greene] might have more input as he mainly implemented his version because he
thought it was interesting.
Unrelatedly, I think it would be nice if we could get to a point where there's just
one base 64 implementation across all of the WildFly project family which has all of the
various capabilities we need. However this isn't possible without adding a dependency
(on wildfly-common perhaps?) to Elytron (and of course moving this stuff there) - which is
something [~dlofthouse] would have to comment on.
End rambling brain dump
Clean up Base64
---------------
Key: ELY-43
URL:
https://issues.jboss.org/browse/ELY-43
Project: WildFly Elytron
Issue Type: Feature Request
Components: Utils
Reporter: Darran Lofthouse
Assignee: Farah Juma
Fix For: 1.0.0.Beta1
The Base64 implementation has been split out of PasswordUtils some additional steps are
needed to finish cleaning it up: -
- Look at switching to input and output streams instead of the custom iterators it is
using.
- Consider the ByteStringBuilder from SASL
- As potentially more visible ensure clearer method names.
- Ensure adequate javadoc and cross referencing of standards supported.
e.g. If we implement an RFC ensure the number is referenced.
- Testing of each variant
- Consider optional support, e.g. decoding a padded String
- Go beyond testing we can decode what we encode and ensure pre-encoded values can be
handled adequately.
Any other clean up here that seems relevant.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)