First, before I go into this, setting some expectations.
I don't think "moving to a web framework" is the right way to look at
LedgerSMB's direction. This way of framing things presupposes that
LedgerSMB will always be primarily a web app, and I don't think that's a
good idea. We already have users who are up against the limits of what you
can do in a web app format and eventually I would like to ensure that we
have thick clients as well, and I don't think the "primarily a web app" is
necessarily a good model esp when we get into higher volume transaction
processing.
So that objection is limited to how to think about the question, not
necessarily the substance of whether or when to use a web framework going
forward. Those thoughts are below.
On Mon, Sep 3, 2012 at 8:00 AM, Ed W <li...@wildgooses.com> wrote:
> Hi, I have some experience of using the perl web framework Mojolicious
> and whilst there are a number of very nice web frameworks, I would like
> to suggest the use of Mojolicious for LSMB.
>
> I think you can gain a very good working knowledge of the framework if
> you watch the first couple of videos:
> http://mojocasts.com/
>
> and checkout some of the (very decent) docs, eg here is the :Lite docs.
> Note you would *not* build LSMB using the :lite framework, but I think
> it's a compact way of quickly seeing what you get (the :Lite framework
> is more like Dancer)
> http://mojolicio.us/perldoc/Mojolicious/Lite#SYNOPSIS
>
> The author of Mojolicious is one of the original developers of Catalyst
> and claims that he has learned from the experience... As a result,
> arguably there are faults with Mojolicious in that it tries to be
> "dependency free" compared with Catalyst being considered "module
> hell". In fact if you check the codebase it's actually very small and
> elegant and extremely well put together. We can all learn a lot by
> looking at the code
>
Good to know.
>
> Mojolicious is not what I would call an MVC architecture since it
> doesn't have a strong basis for the "M", so it's really more of an
> opinionated "VC" with you left to implement the "M" however you wish...
>
> In the case of LSMB what I can see is that the code base is already
> heavily modularised and so this almost completely becomes the "M" for
> mojo. What you pickup for free is:
>
> - URL Routing extracted and handled in an external and flexible way
> - Strong CGI handling which abstracts all the interfacing with a web
> server. Comes with a built-in web server and can integrate with plack.
> Supports and abstracts integration with almost any web "verb", eg it's
> simple to handle GET/POST/PUT, web sockets, Event Source, etc, etc.
> - Persistent cgi and route caching
> - Flexible view template handling, eg responding differently to Accepts
> header: JSON/HTML/PDF etc
> - Strong support for automated testing...
>
Perl tends to be this way generally.
> - Which implies: easy external automation of various tasks, define new
> "Commands" which could be used either as a form of API or to automate
> certain tasks:
> http://mojolicio.us/perldoc/Mojolicious/Commands
>
I think that the key things we get from this have to do with request
handling (a lot of the things we use LedgerSMB.pm and LedgerSMB/Form.pm
for). This is valuable. Not sure it is possible to do with the SQL-Ledger
code in a sane manner however.
>
> Of course it's not a "drop in" task in practice, but I think if you
> examine the framework you will see that at least conceptually it's a
> "drop in" for the existing code and various pieces can be migrated
> across to the services provided by Mojolicious on a piecemeal basis
>
> Just a light recommendation.
>
The key issue as far as I see it at present is that right now we have two
codebases. One supports code caching reasonably well. The other (the one
we inherited) is a mess. Getting it to work on Starlet was not a simple
task (took me over a day of just fixing bugs and troubleshooting) and in
the end if you don't fork, run, and die (i.e. each child serves one request
only), after 5 runs of the chart of accounts report or 10 runs of the sales
invoice screen (yes, each line entered counts), something gets corrupted
and old code will just show internal server errors. I expect that until
at least 1.6, running LedgerSMB on Plack or equivalent will be a bit of a
specialist area. It requires knowledge of tools beyond what I'd like to
require those who run the software have. I doubt these problems are
specific to Plack.
Also there are a couple things that are higher priority for me at least.
These are:
1) Getting a really good cross-language database interface in. We still
need some work in this area. Probably during the 1.5 development time, I
expect to try to build a CPAN module to do this, and then we can begin to
move code over onto it in the 1.6-1.7 timeframe.
2) Getting rid of the SQL-Ledger code. This will take some time. However
1.4 and 1.5 will make large strides in this area, and 1.6 will likely
continue that.
At the same time, I think moving onto someone else's code for request
handling would be a good thing. I would just prefer not to invest a lot of
effort in it while the codebase is in the kind of flux it is at the moment,
and so far Mojolicious seems like the obvious choice. So I guess with that
in mind, I would not be opposed to contributions in this regard, but I
think we'd want to put them into addons/ for a release cycle before merging
into mainline in order to better understand where we have problems and what
needs to be done about them.
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
