Re: Proposal for 1.5: Move LedgerSMB to Dancer

Hi;

First, great points. It is clear I didn't really discuss the case for moving.

On Tue, Aug 12, 2014 at 2:05 AM, Erik Huelsmann <..hidden..> wrote:

Hi Chris,

There has been some discussion in the past I have had with folks about moving LedgerSMB to Catalyst.

Ok. I can't remember I was around when this discussion may have happened. Possibly the same applies to others. Are there any records on the web that you can refer us to? If not, what are the assumed benefits for such a switch?

These were mostly around the beginning of the 1.3 development process iirc. Unfortunately I think they were mostly on IRC.

The major benefits mentioned were (as of 1.2):

1. No more hand-coded handling of HTTP headers at any level.

2. Greater flexibility in running over mod_perl, plack, cgi, etc. I.e. no dependency on CGI::Simple, or gateway-specific modules.

The major problem with Catalyst which doomed the effort for us is that Catalyst is fairly heavy-weight and we weren't really sure how much we wanted to commit to a heavy-weight framework. While one can always diverge from the framework, there are issues of fitting into the community, etc. and that can be a barrier to contribution.

However, we aren't really at the same place we were there. The benefits for moving to Dancer are a bit larger now than they were before 1.3's release.

As I see it, Dancer would:

1. Allow simpler installations with the built-in web server and no Apache, nginx, etc.

2. Reduce the amount of code we have to maintain for web services

3. Replace our current plack wrappers

4. Replace parts of our Request object, part of our Form object, and part of our LedgerSMB.pm module.

5. Give us a better way of handling URL's, but we'd probably need to think this through.

This sounds harsh, but isn't intended as such, but: what's the rush? I mean: any switch is likely to be much easier when we get rid of the old code. If we make 1.5 be the release where we achieve that goal, isn't 1.5 big enough?

Right. I certainly think this needs to be prioritized behind the financial rewrite. However, as I think about this, migration will not be something that happens right away, but will be one of those very slow projects which simmers for a major release or two while we hammer out all the details.

Then, for 1.6, we can switch frameworks if we want or need to. One thing that I do find important though is that releases have clearly visible *user* benefits as well as technical improvements.

The key user benefit here btw would be in installation, i.e. for small users, being able to fire up a packaged web server and away you go, no application-specific configuration needed. So my thinking is we should work on it starting in 1.5, and plan to release this maybe with 1.6? Maybe it happens sooner. I don't think it is that much coding work, but it may require a lot of discussion and design work.

Nobody in his right mind is going to switch accounting systems for the sake and sanity of the developers of such a system :-)

True, but if we do things to make developers more sane, they can help their users switch more easily ;-). Also code quality and robustness is a big deal.

I do think this is something we want to be looking at particularly as we add more in the way of web services, and move towards a more ajaxy interface. However, this is not time critical as you point out.

Hope this helps,

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.

------------------------------------------------------------------------------

_______________________________________________
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