Re: Proposal for 1.5: Move LedgerSMB to Dancer

[Chris Travers <..hidden..>]

On Sat, Sep 6, 2014 at 7:43 AM, Lyle <..hidden..> 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 <..hidden..> 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
>> ..hidden..
>> 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
> ..hidden..
> 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
> ..hidden..
> 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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel