+1 for keeping it pluggable and providing optional implementations if there are real-world use-cases for them.
regards, gerhard 2012/11/15 Mark Struberg <[email protected]> > Hi! > > How many state key algorithms do we really need? Since all the state keys > are encrypted later on anyway, this has NOTHING to do with security (just > to prevent off-topic discussions)! > > > [ ] We need exactly one good which is well performing and ensures that no > collision can happen. > [ ] We should make it pluggable but only provide one good > [ ] Let's keep our many (mostly overlapping) implementations. They only > got introduced in 2.1.9, so nobody is using them right now, but keep them > nontheless. > > Here is my vote: > [ ] We need exactly one good which is well performing and ensures that no > collision can happen. > +1 > > [] We should make it pluggable but only provide one good. > > +0.7 > > If we like to go that route, then we should at least restrict the key to > either String or byte[] to make the API much easier. It doesn't make sense > to keep this as generics imo. > > LieGrue, > strub > >
