Re: Proposal for LedgerSMB 1.5: Refactor and move some utility functionality to CPAN

Hi everyone;

After 1.4 is released I would like to start moving the following functionality to CPAN:

1. Stored procedure call interface (call_procedure)

2. Stored procedure-> object property mapping interface (exec_method)

3. Moose wrappers around these, and

4. User permissions discovery

5. Helper modules (LedgerSMB::PGDate, LedgerSMB::PGNumber)

There are a number of reasons why I think that this would be a good idea:

1. These are all potentially generally applicable pieces of code. They are potentially reusable well outside LedgerSMB, and they provide potential integration points for other applications.

2. They may be of interest to other developers. To the extent that they are, they represent a potential source of outreach for LedgerSMB

3. Over the years, a good deal of cruft has built up in the interfaces. It would be good to redesign, generalize, and modularize these so that we can have better contracts between elements of the program.

My current plan is to create what is essentially a toolkit for incorporating stored procedures into objects in Perl and then have our current interfaces be basic wrappers around these. The wrappers will still be necessary because many decisions we have made regarding tracking things like application state between modules can't be assumed in other environments.

A few questions I have for folks here:

1. Licensing. In general I have been trying to put new language bindings under permissive (BSD-style) licenses for the simple reason that it gives people more peace of mind if they are integrating proprietary applications with LedgerSMB. This also has the advantage of following what the PostgreSQL community is generally most comfortable with. Are there any concerns about this? Our actual object framework would still be GPL v2 so no changes of licensing in our project. It would just mean that there would be integration points available under more permissive licenses. The other option is "under the same terms of Perl itself" which protects us better against proprietary forks, but I am not at all sure that is much of a fear.

2. Any feedback on the general structure of what I am proposing? Is this likely to cause significant packaging headaches? Should we look at offering a LedgerSMB with these bundled?

Best Wishes,

Chris Travers