Make something amazing, for anyone, at DrupalCon. Standard prices end on August 26.
Add PHP QR Code as new engine to the module.
I'd like to suggest a different approach.
Essentially, the different engines provide options for users who may be in varying hosting environments; some are easier than others. Google graph engine provides an out of the box solution for users who want a "zero effort" install. Similarly, for those users who don't have access to install libraries on their host, this is one option. It's not ideal since it requires accessing a third party service to generate the code, which could potentially leak information to google (sensitive or otherwise; it depends on what's being encoded).
libqrcode is an option for those who have access to install libraries on their server. This is preferred since it will likely be faster and not have a 3rd party service dependency.
What I propose is doing away with the engine support (since the end result is essentially the same), and instead checking in hook_requirements for presence of libqrcode, and if it's there, use it; otherwise fallback on Google Graphing API. This has the added benefit of simplifying installation of the module.
My inclination is to keep the flexible engine support since Google and libqrcode are not the only good options, especially down the road if/when things change. E.g., I wouldn't be surprised if Google changed or completely pulled that API some day. If we can do that and make the install smoother, I'm all for it.
Not a fan of a "fallback" mechanism. Let the site administrator decide what engine he wants to enable based on his hosting environment.
Hey claudiu.cristea! Glad to be on the project, and nice to meet you!
I'm okay with leaving in options, but to the layman I think there needs to be some understanding of what the alternatives mean. It took me a bit to determine what the difference between the engines were, and the impact they may have to site performance, etc. Possibly this is a documentation task then?
As for engine support, there's an incongruity introduced when providing no default engine. Perhaps do away with the module dependency on engines, then, and select the proper engine based on which option the user selects via some module_load_include magic?
As an example, we could move the engine code into an OO construct with a defined interface, and make things simpler to implement/modify down the line. I've done this with some custom modules in the past and it improved maintainability and reusability significantly.
Right now I know:
These are all different as nature... They are build for different environments. First code was written only for Google Chart API. I came with the idea to make QR Codes pluggable (see http://drupal.org/node/838198).
But I'm open... Maybe providing a patch will clear out the issue :)
Drupal is a registered trademark of Dries Buytaert.