I don't know for other modules, but with Zeitgeist already including its own date library, this would certainly some kB off of it. What's worrying me more is two things: - do we really want to maintain two fork off PEAR, as you mention yourself - this means a lot of code to be parsed that won't really be used afterwards in most cases. selective loading, as in php5's _autoload mechanism, would obviate the second point, but only works out of the box with PHP5 (which would fit nicely with the GoPHP5 thread)... and with classes, not pure functions. ----- Original Message ----- From: "Karen Stevenson" <karen@elderweb.com> To: "Drupal Dev List" <development@drupal.org> Sent: Friday, June 22, 2007 4:05 PM Subject: [development] Date Calc and ADODB date library
I have decided that it would be really useful to add the PEAR Date Calc and the ADODB date library to the Date API by reworking the original code to use Drupal coding conventions and styles and making them available as natively-available Drupal include files. Both have BSD licenses, so my understanding is that it is OK to do this. Anyone know for sure if that is true? And does anyone know exactly what parts of the original license info should be retained in the reworked code or how I should attribute the original modules/authors?
Also, as I work through them, it occurs to me that once they're 'Drupalized' they might potentially be nice additions to Drupal core. They could then be used by a wide variety of core and contrib modules that do things with dates and schedules and calendars without the need to duplicate all that code.
[...]
The risk of doing this is that someone needs to keep up with the original code in case there are bug fixes that need to be ported to our fork, but both of these libraries are very stable and haven't changed much.
Together they would make many things possible, or at least make them easier.
Thoughts??
Karen