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
------------------------------------------------------------------------------
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

Reply via email to