baby sleeps again I've spent a lot time recently triaging bugs for I've enjoyed the process, and respect as a widely used Perl module. I'm not in love all aspects of module. I don't use or recommend the HTML generation features-- I recommend using HTML template files and HTML::FillInForm for filling them.

Whenever I think about how I'd like to change,what I have mind is often the same choice that CGI::Simple made. There was a time years ago that I focused my attention on CGI::Simple and tried it in production, only to be bit by a compatibility issue, so I reverted back to I don't remember what the specific issue, and it's likely been fixed by now. But the pragmatic point remained with me: CGI::Simple may have clean code and a good test suite, but it's not necessarily free of defects and in particularly it lacks the vastly larger user base that has to provide real world beta testing.

I recently took another look at CGI::Simple, it's cookie handling implementation, and its bug queue. One thing became clear: CGI::Simple forked from in 2001, and they have not evolved in parallel since then. Each has had different bugs filed against it, with some issues fixed in one and not the other. They both have test suites, but they have evolved with different test coverage as new tests are written to respond to bugs filed against one particular module.

And, unfortunately for the better design of CGI::Simple, it is that continues to receive far more of the attention and updates. (Although to be fair, some of this relates to the HTML functions, which are intentionally omitted from CGI::Simple).

I would like to say that CGI::Simple is a clear path forward from if you are willing to let go of the HTML generation functions. Unfortunately, the current situation is ripe for running into subtle differences that have been created since the projects forked about eight years ago.

My vision for a solution is simple: and CGI::Simple should be maintained together. Where their features overlap, the combined project should have the best version of the documentation from both projects, the best code from both projects, and the combined test coverage of both projects. CGI::Simple is intentionally incompatible in a few ways in the name of better design, and I support that. Still, the projects should strive to maintain compatible whenever possible to make it easy for people to transition from to CGI::Simple. When a change comes in that could affect either module, it should be changed in both modules.

A great example of a possible collaboration point is the request to add PSGI support to Ideally if the proposal is accepted, it could be added to both and CGI::Simple at the same time, with the same API, tests and documentation.

Using rsnapshot with systemd

Published on August 26, 2016