New PHP QR Code engine

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.

Thoughts?

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.

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.