Re: Proposed Architecture Changes in 2.0 (Request for comments)

[Chris Travers <..hidden..>]

On Sun, Mar 7, 2010 at 6:37 AM, David F. Skoll <..hidden..> wrote:
> Kaare Rasmussen wrote:
>
>> Use Catalyst. It lets you do what you want. It only steps in where you need
>> it.
>
> I'm not so sure about that recommendation.  Having built some small
> projects with Catalyst, I found it fairly large and unwieldy, quite
> demanding of prerequisites and in a frustrating state of flux.
> (Granted, this was about a year ago... things may have changed.)
>
I think the fundamental question really should be:

Given that our approach doesn't get to use some of the major parts of
a framework (authentication, model), and given that the view logic is
not likely to require much of a rewrite between 1.3 and 2.0, does
moving to a pre-existing framework simplify or complicate our lives as
developers?  (Actually, I think there are just a few lines of code
that will have to change in our view handling.)

The answer there is "I don't know" which is why I am asking.

Currently our "framework" is cobbled together pre-existing pieces,
with large parts outsourced to PostgreSQL.

Basically the minimal portions that need to be rewritten for 1.2 are:
1)  Dispatcher script
2)  Workflow scripts rewritten in 1.3 need slight alterations
3)  DBObject modules need some alterations in some cases (Company.pm
and Payment.pm need to be refactored) but these are more coding
standards issues.
4)  Refactoring of LedgerSMB.pm, LedgerSMB/DBObject.pm, and adding
LedgerSMB/Request.pm
5)  Contact info database needs some refactoring
6)  Some changes in directory structure would be helpful
7)  bin/gl.pl, LedgerSMB/GL.pm, bin/aa.pl, LedgerSMB/AA.pm, etc.

Additionally, I would like to see Auth and Session handling separated
into different pluggable modules.  That would make it easier to
implement Kerberos auth.

If we go to a framework, maybe it saves us some time on #1 and #2, and
parts of 4, but it means we end up having to re-implement other
things.

Finally, I would like to be thinking a little bit here beyond the web
interface.  In particular, I would like to see a framework that would
serve as a basis for thick client apps as well.  The major reason for
this is that controlling POS hardware from a web app is difficult,
kludgy, and brittle.  I have one customer I support in this area and
it's a pain to try to troubleshoot why pole displays sometimes lag or
don't update, or the like.  I would really like to build a thick
client for them....

Best Wishes,
Chris Travers