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 <[email protected]> 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
> [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
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Reply via email to