Hi, Just some thoughts regarding this topic.
I started to play with the stored functions in the database. I had no time to make a heavy test of the recent version of lsmb to see, how it is working. I really prefer the idea to move the core logic to the DB, to eliminate core bugs, separate the core logic and the UI somehow, I have to dig deeper in the 1.4 to see, where we are :) Cheers, István ----------------eredeti üzenet----------------- Feladó: "Chris Travers" [email protected] Címzett: "Development discussion for LedgerSMB" [email protected] Dátum: Tue, 12 Aug 2014 02:36:04 -0700 ---------------------------------------------------------- > > >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 -> http://efficito.com/] > > > > > >__________________________________________________ > > > >------------------------------------------------------------------------- >----- > > >__________________________________________________ > > >_______________________________________________ >Ledger-smb-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > > > >
------------------------------------------------------------------------------
_______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
