Re: Proposal for 1.5: Move LedgerSMB to Dancer

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