Re: Plan after rc2

Hi Chris,

Today I am hoping to finish up the work on the major blocking issues for RC2. Perhaps we can get RC2 out early next week.

One thing I expect to do after RC2 is try to create a simple Dancer wrapper for easy install. I am allocating no more than about 8 hours to try this (and would more likely give up if I am not close by 4-6 hours).

If this works, we can ship with Dancer as an option in 1.4, and consider porting to the framework in future versions. If it doesn't, we will have a list of likely problems to discuss.

Shipping with a Dancer option would make installation a lot easier for many folks since Dancer comes with its own web server. It would also provide greater flexibility since Dancer apps can be run in every way plack aps can be (CGI, mod_perl, fcgi to name a few).

Summarizing our conversation we just had on the topic:

1. While I agree that having a Dancer wrapper helps us in the customer-friendly department due to Dancer's built-in HTTP server, I would like to argue that 1.4.0 (GA) is still our top priority and this wrapper should IMO not lead to delays in releasing 1.4.0 -- which we agree on, really.

2. In the above message, you seem to imply that creating the Dancer wrapper would be enough to learn if Dancer is a good fit for us. While I think that creating a wrapper gives a bit of a feel for Dancer, it's probably not enough to see what's involved for us to move there. I also feel that just starting to refactor parts of LedgerSMB to see what works, isn't a good approach. Going over our options, we came to the conclusion that we have a separate (small) webapp which needs refactoring to become a true webapp anyway: setup.pl. Setup.pl needs everything from Dancer that the main webapp needs as well and it needs it in roughly the same way. So, by refactoring setup.pl "onto" Dancer, we'd be killing two birds with one stone: (1) give setup.pl the refactoring it needs; and (2) gain the experience with Dancer that we need in order to determine if "it will work for us".

If we do the refactoring required for (2) in a separate branch/repository, we can have a go/no go at the end before we merge the refactoring onto trunk: by that time we should have enough experience with Dancer to evaluate the pros and cons. We should have some insight into what it's going to take to take real benefits from the required refactoring: we discussed that our current mix of request/response handling with database handling and other setup tasks is far from ideal. To really reap the benefits from moving to Dancer is to refactor the entire request handling phase.

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.