[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: After 1.4, looking towards baby steps to 2.0
- Subject: Re: After 1.4, looking towards baby steps to 2.0
- From: herman vierendeels <..hidden..>
- Date: Fri, 3 Jan 2014 12:54:54 +0100
'but an intelligent database which can be the center of the enterprise'
I like this idea.
But i think, once 1.4 has its own tag, we should do a thorough review
of the db-schema.
relations and fields in and between company,entity,entity_credit_account
company should be a top-level table being able to refer to
should not contain field entity_id?
2014/1/3 Chris Travers <..hidden..>:
> Hi all,
> After we get 1.4 up and out the door, I am looking to see what we can do to
> help get pieces of our code more ready for 2.0. Here are immediate
> proposals I would like to make:
> 1. Break off the most obvious pieces of the db schema into Postgres
> extensions and publish them on pgxn. These could be bundled with LedgerSMB
> as well, but should be available to other apps as well.
> 2. Break off simple, mature functionality in Perl modules into CPAN
> modules. This would focus on a stable API, better backwards compatibility,
> I would propose focusing on accounts storage and menu structures first, and
> then maybe the contact management side. Once something is broken off, I
> would like to try hard to maintain backwards compatibility so this should
> only be for things which have become relatively stable in terms of base
> Here are the impacts I could see for packagers:
> 1. Packagers might want to package the extensions and cpan modules
> separately. One advantage to this is that if changes need to be made for
> different Pg versions they can be. The nice thing is that aside from
> bugfixes, it should be as simple as uploading once and then not having to
> worry about it until a material change comes in terms of requirements (and
> those would be minimized).
> 2. These could still be bundled all together if they are seen as closely
> tied, but it would affect final target paths.
> As for licensing, I would like to propose the following:
> 1. Major integration points I would like to be licensed under terms
> functionally identical to PostgreSQL (i.e. 2-clause BSD or similar). This
> reduces questions of licensing that integrators may have. As we simplify
> the Perl code and move more logic into the database, it seems to me that it
> may be good to move more of these to a BSD or similar license. Note that
> our current PHP classes are under such a license.
> 2. Areas of complex business logic I think for the time-being should be
> under the GPL2+. As long as client libraries are under more permissive
> licenses I don't see anything we'd gain by making these more permissive. As
> it is we currently have the issue that someone could fork and upgrade the
> license and we'd either have to follow them or not merge anything back.
> Some *very* generally applicable parts might do well to be released under a
> BSD-style license (the menu system comes to mind) in the hope that other
> open source projects may pick it up and contribute but I think they'd be a
> small minority.
> The licensing ideas are guided by the idea that what we are really hoping to
> bring to customers is not so much a web app or a web app framework but an
> intelligent database which can be the center of the enterprise. From this
> viewpoint what we are doing in Perl mostly is trying to create interfaces
> for the database, while the major logic is in the database. If folks want
> to use our API, I am happy for them to do so.
> Anyway, thoughts?
> Best Wishes,
> Chris Travers
> Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Ledger-smb-devel mailing list