Beautiful Code [159]
my $status = cmdsend('test.pl', $a, $cmailclient, $select,
'newuser', $USER);
return $status unless $status =~ /^\+OK.*with password (.*)$/;
$PASSWORD = $1;
1;
}, 1);
...
Secure Communication: The Technology Of Freedom > The Functioning Prototype
11.6. The Functioning Prototype
For the first prototype, I used a simple object persistence module, Persistence::Object::Simple (which my friend Vipul had written for a project we'd worked on earlier) to whip up a basic user database. Using persistent objects helped keep the code clean and intuitive, and also provided a straightforward upgrade path to production database engines (simply create or derive a compatible Persistence::Object::[§] class for the database engine).
[§] "There's More Than One Way To Do It," a central tenet of the Perl way of life.
In late 2002, Matt Sergeant created another simple prototype-to-production path for Perl hackers, DBD::SQLite module, a "self-contained RDBMS in a DBI driver," which can be used for rapid prototyping of database code without the need for a full database engine during development. Personally, though, I prefer the elegance and simplicity of persistent objects to having my code littered with SQL queries and DBI calls.
Mail received into the Cryptonite system was saved to regular mbox files, which worked fine for the prototype. Of course, a production implementation would have to use a more sophisticated mail store. I decided to use PGP itself as the encryption backend, to avoid rewriting (and maintaining) all the encryption functionality already contained in PGP.
GnuPG was coming along, and I kept in mind that I might want to use it for cryptography support in the future. So, I wrote Crypt::PGP5 to encapsulate the PGP5 functionality in a Perl module. This module is available from CPAN (though I haven't updated it in ages).
For the cryptographic core of Crypt::PGP5, I could have used the proprietary PGPSDK library, but I would have had to create a Perl interface to it, which would likely have been more work than just using the PGP binary. So, with a healthy dose of Perlish laziness and keeping in mind that TMTOWTDI,[||] I decided to use the Expect module to automate interactions with the PGP binary, using the same interface that's available to human users of the program. This worked well enough for the first prototype.
[||] "There's More Than One Way To Do It," a central tenet of the Perl way of life.
A basic web interface was developed, using the Text::Template module, to populate HTML templates. The Cryptonite::Mail::HTML module contained all web-interface-related code, including session handling.
The prototype system was ready after just three months of part-time coding. It implemented a full web interface, basic MIME support, OpenPGP encryption, decryption, signing and signature verification, online new user registration, and a new and interesting alternative to login passwords for authentication: PassFaces from ID Arts.
Secure Communication: The Technology Of Freedom > Clean Up, Plug In, Rock On…
11.7. Clean Up, Plug In, Rock On…
After developing the initial prototype of Cryptonite in Costa Rica, I continued working on it independently. After a much needed cleanup of the code (prototype development had been hectic and had left not much time to refactor or test the code), I worked on a number of Perl modules and components that would be needed next, to make the jump from a simple prototype to a scalable product. These included Crypt::GPG (with an interface almost identical to that of Crypt::PGP5, so that switching to GnuPG for the crypto operations in Cryptonite involved little more than a single-line change to the code), and Persistence::Database::SQL and Persistence::Object::Postgres (which provide object persistence in a Postgres database, with a similar interface to Persistence::Object::Simple, making the backend database switch quite seamless as well).
Persistence::Object::Postgres, like Persistence::Object::Simple, uses a blessed reference[#] to a hash container to