Hi Herman,

On Fri, Jan 3, 2014 at 3:54 AM, herman vierendeels <
[email protected]> wrote:

> Hi Chris,
>
> '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.
>

Or at least parts of it.


> e.g.
>  relations and fields in and between company,entity,entity_credit_account
>  company should be a top-level table being able to refer to
> customers,vendors,employees ?
>  should not contain field entity_id?
>

Yeah, the contact schema is due for a real review in light of experiences
in 1.3 and 1.4.  I think this is the first step in breaking it off into an
extension.  One of the key things is that when we break it off, I think we
want to have some confidence that the API isn't going to change in
backwards-incompatible ways which means moving back and thinking through
all of these things.

Two areas which are higher priorities for me to be honest are the menu
tables and the account tables because I think these are actually closer to
where we want them.  For the account tables it also gives us an option to
start rethinking how we really want the db design to work for financial
transactions and some changes will probably need to be made there (for the
menu, I would like the tables to be able to accommodate multiple menus
within them, so they could be used for multiple related apps hitting the
same db).

But the contact side has a lot of complexity there and we may want to think
carefully about other aspects to the model (like whether we want to be able
to, within the db, attach persons to companies, etc).  This is a
significant chunk of code and the review may take a while.  So definitely
that needs to be reviewed.

Best Wishes,
Chris Travers


>
> Thanks,
> Herman
>
>
>
>
> 2014/1/3 Chris Travers <[email protected]>:
> > 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,
> > etc.
> >
> > 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
> > functionality.
> >
> > 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
> > lock-in.
> > http://www.efficito.com/learn_more.shtml
> >
> >
> ------------------------------------------------------------------------------
> > 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
> > Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Ledger-smb-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> >
>
>
> ------------------------------------------------------------------------------
> 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
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Ledger-smb-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>



-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
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 Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Reply via email to