Closed xenoterracide closed 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.
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
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
At some point it might be worth it to design a separate encoding role that a Digester has composed.
Or maybe we just need a Strategy based encoder