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

[Chris Travers <..hidden..>]

On Sun, Mar 7, 2010 at 4:18 PM, David F. Skoll <..hidden..> wrote:
> Chris Travers wrote:
>
>> 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?
>
> It depends on the framework.  I think Catalyst will eventually simplify
> your lives, but will initially complicate it as you navigate the learning
> curve and the rather numerous prerequisites.  All the prerequisites will
> also make it a bit harder for users to install and test the code.

I have given a lot of thought to this and I am starting to think we
may want to make the main code a "reference implementation" with a
custom but light-weight framework and encourage porting to various
frameworks that support TemplateToolkit or the like, or similar
things.  Catalyst seems like the obvious option here, but having lots
of abstraction layers doesn't help someone who is, say, trying to come
up with a Python-based add-on to understand what exactly the code is
doing.....

However, there are a lot of reasons why someone would want to work on
a framework (RESTful web services for example might be a lot easier to
address there).

My tentative recommendation here (tentative, and open to change if
good arguments are raised against it) is to suggest that LSMB 2.0
should have a light-weight, transparent framework, and that we should
look at facilitating ports to whatever frameworks (and languages!)
various folks want.

> How do you see that playing out?  A REST-based API?  I'd love to see
> something like that.  Or do you envisage writing enough of the logic
> right inside PostgreSQL so a thick client could just make function calls
> in PL/pgSQL?  (I think the Skype developers are very big on that approach.)

The nice thing about the way we are moving is that it allows for
either type of approach.  However, the logic required to make calls to
PostgreSQL is fairly thin.  Furthermore, for POS environments, you
really want as few delays as possible, so it's better to directly
connect.  Hence a Perl/TK (or with wxWindows) with the LedgerSMB
DBObject classes would make the most sense.

But RESTful web services would provide a great number of benefits as
well.   Certainly having something based on our service oriented
database architecture doesn't preclude a service-oriented web
structure app based on it.

Best Wishes,
Chris Travers