I had to give this module a poor rating because it uses a module called "ESL" in its core code which cannot be found anywhere within CPAN.
I had just started looking for a module to talk to freeswitch when I saw this one. While there are not many modules for this and something that ties to a event framework like anyevent is nice, this module cannot be used in its current form by anyone unless its fixed.
There is no documentation on how to go about getting that module if it is possible at all. This basically makes this module unusable and useless in terms of a public release on CPAN. Perhaps author forgot to put the other module on CPAN?? In either case at this state it is better to give this module the lowest rating till its usable.
packing the iv, key and specifying no header, I do not get the expected result. I wrote my own function to run a simple CBC using DES_EDE3 module instead and it works. Maybe the module needs more documentation on the way to use it? I would recommend adding unit tests to check if the algorithm actually works properly with all ciphers that it claims to support. You may use the above cipher as a example.
@Peter above, the low rating from you was well deserved. In my defence I am new here and was just trying out the ratings. I hope me setting the rating to undef will satisfy you that my intent was not ratings abuse!! I have mailed the webmaster to delete this rating.
I have fixed the documentation for add(), thanks for pointing that out!
The faulty syntax in the documentation to add() might have confused you about its usage. The add is passed File Handles to create a new File entry.I think File Handles are more appropriate than File Descriptors for use here. As for dealing with temporary files, you don't have to create a temporary file to use this module, thats the idea behind replacing Filename(The way its used in HStore) with File Handles in add(). The reason I went with FHs is to make this code suitable for use with online systems where you can get a file handle of the uploaded file which you can directly pass to add() to get your file stored on a disk with a numeric identifier. HStore internally gets a handle from the filename that is passed to it anyway, so why force a program which has only got a filehandle from its source, to write a temporary file to get a filename for add()?? on the other hand if the user has access to a file name he can still create the file handle and pass it to add().
I think using file handle instead of filename is much cleaner for this interface.
As for borrowing from HStore, it is explicitly mentioned in the perldoc along with credits to the author of HStore that this module is based out of HStore, I had a e-mail discussion with Alexandre(author of HStore) about my plan to write this module and about the changes I planned for the interface to this module compared to HStore, before I set out to write this module.