On Thu, May 23, 2013 at 11:20:22PM -0700, Chris Travers wrote: > 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 >
I like this idea. Other users outside of LedgerSMB may find flaws or suggest new features that might be useful. I have occasionally found some things in other CPAN modules and had a good response from the author. > 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. I always prefer BSD or even more permissive licensing. If someone can then sell a proprietary version, they might be willing to submit a module with the same kind of licensing. No guarantee of that, of course. But why not? There is something else that does happen. Companies close. People retire. A contract for their software may end. Sometimes people die. This actually happened to me during one project. All of their proprietary software may suddenly become available with a BSD license. Chris Bennett ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
