On Sat, Sep 6, 2014 at 7:43 AM, Lyle <[email protected]> wrote: > I'm very much for moving to a framework and Plack. It makes it much easier > for new developers to understand and contribute to the code. Taking > advantage or persistence with FastCGI or mod_perl through Plack would speed > LedgerSMB up a great deal. I'm not sure how prone the existing code is to > memory leaks?
There is a lot of old SQL-Ledger code which is not persistent-safe. I set up 1.3 running under Starman once and found that at least with the versions of the software I was running, some old screens would crash the Perl interpreter if they were persisted. What I did was effectively preload, then fork-run-die, sort of like a "cgi-lite" approach. Since the crashes would occur on the nth reload, I could never track down the problem. It might be some sort of a "scope leak" problem of the sort that bit us numerous times with the same code when Perl 5.10 came out. Additionally in 1.3 and earlier I would not trust reports to be persistent. This problem was resolved in 1.4 and reports in 1.4 can be assumed to be persistence-safe. Hopefully soon I will be able to retry with 1.4 and see how much the situation has improved. However what I have decided to do next (after I get the next gen stored procedure mapping modules done, which should happen today) is get started on a Dancer app that does what the setup.pl currently does (db setup, upgrade, backup, and initial user management). I expect to try to support 1.3, 1.4, and current master with that app. That will give us a tool for both gradual upgrades of db's on hosts sharing 1.3 and 1.4, as well as a discussion piece for what dancer brings. Best Wishes, Chris Travers > > > Lyle > > > On 03/09/2014 00:52, Chris Travers wrote: > > Some new thoughts having spent a little more time with Dancer. > > > On Tue, Sep 2, 2014 at 10:34 AM, Louis <[email protected]> wrote: >> >> >> In the following, you can read "your application" as "LedgerSMB". >> >> Well, every web application is to a certain extent either using a >> framework or creating their own framework. Eventually you will choose a >> template method and other middleware and have to manage/develop your >> application around them. > > > This is true. One of the major differences coming in 1.5 is that we are > breaking our DB framework out and releasing it on CPAN separately. This is > entirely unique in db integration frameworks as far as I have seen and it is > very, very different from the normal ORM approach. > > So that leaves the http handling bits, the middleware business logic, the db > components, and the front-end. Each of these either has to be a framework > or extend a framework. The question is which parts of this do we want to > own and be responsible for? If the front-end basically ends up using Dojo > and the HTTP handling bits end up using Dance, that leaves us with a db > framework, a middleware accounting framework, and a frontend application to > maintain. > > A big problem btw is the general lack of Dancer directly playing well with > non-dancer apps. I can't wrap LSMB in Dancer. I can have them coexist via > Plack however. >> >> >> While choosing a framework limits some of your choices, it allows other >> folks to more easily integrate your application into a larger system. Of >> course, framework choice can have a big effect on this. In my case, I was >> thinking that the ability to write a plugin for ledgersmb to accept >> inventory and vendor information from my bibliographic system. In a >> framework, the plugin or an example there of, may already exist. > > > To be honest, I don't see a huge win in that scenario. There is no major > accounting framework out there of the sort that would make that work easily. > Where I do see a win is in the amount of code we have to maintain around all > of that. >> >> >> Another potential win could be that people working on the framework >> improving and fixing parts of your application as a result of work on the >> framework itself. > > > Right. Or adding back-end plugins for things like web sockets..... >> >> >> It also can stand for your project demonstrating the ability to >> collaborate and cooperate with other projects, which stands in contrast to >> say, SQL-ledger. >> >> I can't say that I have spent hours chewing it over. It is more of a >> knee-jerk reaction to the idea cooperatively using another projects work. > > > We already do that extensively (moving to CPAN dependencies where possible). > > My next step (not quite sure when) is to refactor the database > administration logic into general and lsmb-specific components and then > write a Dancer-based administration app (replacing the current setup.pl). > We would then be able to discuss benefits and costs of Danver specifically > looking at that. >> >> >>> >>> Talking to Chris earlier today, he told me he expected long term benefits >>> on at least >>> these items (I hope you concur and maybe think of more): >>> >>> 1. Creation of an API (due to the availability of a resource->entrypoint >>> mapper and a >>> serializers) >>> 2. Websockets >>> >>> >>> >>> >>> -- >>> Bye, >>> Erik. >>> >>> http://efficito.com -- Hosted accounting and ERP. >>> Robust and Flexible. No vendor lock-in. >>> >> >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> 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 > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > > _______________________________________________ > Ledger-smb-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Ledger-smb-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
