grondilu / libdigest-raku

Raku implementation of various digests
Artistic License 2.0
27 stars 42 forks source link

Work more like P5 Digest using Strategy #2

Closed xenoterracide closed 10 years ago

xenoterracide commented 10 years ago

One of the great things about P5 Digest is I could have a digest object, know it's interface and use it regardless of algorithm. For something like a password hashing program where I might want to allow people to change algorithms this is critical. Below is some speculative thought on how algorithm and implementation

 my $digest = Digest.new(
      algorithm            => 'MD5',
      implementation => 'PP', # JVM/Native by default should select the fastest for current platform
      rounds                  => 5000,  # for algorthims that support such things,
      # additional arguments passed to the digester
 ); # new should return a Digester interface

I think that Digester's should follow a naming convention of Digest::PP::MD5 Digest::JVM::MD5 Digest::Native::MD5 this convention allows for numerous implementations of the algorithm, but aimed at performance on a given platform, where a native JVM MD5 is probably a better choice than either Pure Perl or Native code on that platform. In theory one could also ultimately select Digest::Clojure::MD5 on JVM, should such a module exist.

Digester inteface should at least impliment

Digester.add( @chunks );
Digester.reset; # start over
Digester.digest; # return binary

At some point it might be worth it to design a separate encoding role that a Digester has composed.

Digester.endoded_as('Base64');

Or maybe we just need a Strategy based encoder

 Encoder.new('Base64').encode( Digest.new(...).add( $data ).digest );
grondilu commented 10 years ago

You right about a new method for a Digest object, unifying the interface for various digest algorithms. It's also necessary if we want to be able to provide data in chunks. The thing is that I don't know how to code something like this. It's probably not difficult, but it's not trivial either. Feel free to submit patch, though I'm not very active on github so I may take some time to review it. You may just consider forking this repo, instead.

As far as the naming convention is concerned, I would personally not put anything machine-specific in the name (machine as in "virtual machine"). But that's an issue that goes far beyond digest computation. You should ask #perl6 about that.

About the encoding, I prefer the Strategy method. The Digester object should return only a Blob, imho. It's not its job to encode binary data in various formats.