[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for 1.5: Move LedgerSMB to Dancer

Just some notes on positives and negatives.  I am going to use Ruby on Rails as an example in part because it is not considered.  I think the negative bits are framework-specific.

On Thu, Aug 14, 2014 at 1:45 PM, Leho Kraav <..hidden..> wrote:
On 12.08.2014 23:27, Erik Huelsmann wrote:
> What do you think we have to gain by moving to a framework? Usually,

I'm all for going proper framework on an proper accounting package like

You offload so much gruntwork to a way bigger team.

I think Erik's objection is that to the extent that gruntwork is done along assumptions we find less ideal for our purposes, that is not necessarily a win.

For example, if we were designing an implementation on Ruby on Rails, we wouldn't be able to use the ORM. 


As long as our approach matches the documentation.  Again, putting something which does not do things The Rails Way on RoR would undercut the value of shared documentation in important ways because the application wouldn't match the framework documentation.    In essence the danger here is that framework documentation could misdocument the application.

This is why selecting the right framework is so important for an established project such as ourselves.  For less established projects there may be a larger number of right frameworks but it is still a strategic choice.

Way easier to install usually, as an established framework has long
figured out the solid moving parts.

The installation bit is a big reason I am in favor of moving to Dancer.

Also the question of which solid moving parts are provided and how those jive with what we are doing is a critical question.  Obviously we don't want to use a framework which has conventions which run counter to the decisions we have made as a project because then something has to give.

This leads to the question of why I am proposing Dancer specifically.  Dancer pretty much just focuses on HTTP and input/output wrapping.  It does not offer an ORM or even recommend one.  It doesn't offer a view system.  It basically just does something we don't want to be doing ourselves, namely interfacing to HTTP, web sockets, etc.

It is worth reading what Matt Trout has to say about Dancer and Mojolicious here: http://www.josetteorama.com/all-about-catalyst-interview-of-matt-s-trout-part-3-of-3/

In essence my thinking is that Dancer would be the ideal choice because it is a microframework focusing on only one thing (interaction between web client and web server), and therefore won't intrude deeply on the rest of what we are doing.

Attracts more random contributor traffic to the project, people that
discover LSMB because they are doing something else with the framework.

Very likely more benefits. Sum of totals in my mind overcome most
drawbacks in already semi-long timeframe (up to 18 months).

I think the installation benefits would overcome the drawbacks in a single release.   I may in fact (once rc2 is out) hack together a minimalistic Dancer app with LedgerSMB for 1.4 (without any real porting, just a wrapper for easy installation). 

Secretly I'm dreaming of a proper accounting package built on top of
WordPress CMS presentation system... but sssssh don't tell anyone, I
don't want rotten PHP eggs flying just yet. WP could probably replaced
with another established CMS framework that allows easy custom db models
being added, but right now I'm very in tune with how much easier it
would to build a mindblowing accounting *user experience* there. Also
for your Efficito hosting business, WordPress' multi-site provisioning
capability is quite possibly unmatched by anything.


Looking forward to getting my own SQL-Ledger 2.6.37 -> LSMB migration
going one of these weeks now, so I could actually know what I'm talking
about ;) All I got right now is "SL's user experience is just a
horrible, horrible thing".

Ledger-smb-devel mailing list

Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
Ledger-smb-devel mailing list