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

[Chris Travers <..hidden..>]

On Sat, Mar 6, 2010 at 6:39 PM, Armaghan Saqib <..hidden..> wrote:
> On Sun, Mar 7, 2010 at 4:25 AM, Chris Travers <..hidden..> wrote:
>> Looking forward from 1.3, I am going to propose the following framework changes.
>
> Hi Chris,
>
> I am assuming that what you mean by 2.0 is a total rewrite. In that
> case we can freely choose some existing framework.
>
> I had a look at Jifty framework (jifty.org) few months ago for a new
> custom work. Seems to be buzzword (ORB, MVC, REST) compliant and
> includes its own template engine (as well as mason) and supports
> addons support. (Also resembles Rails framework in some respects.)

It might be worth revisiting the decision to build our own framework.

One thing that is unlikely to change in 2.0 is being close to the db
and heavily utilizing stored procedures, database roles, and the like.
 These things are not typically supported by ORM's, so if we use a
framework with an ORM, we would probably not use the ORM and specify
that choice in coding standards.

This also moves the application from being possibly MVC to being MVC-like.

Given that we would probably end up having to build the authentication
handoff and database interface portions, the question becomes what it
would buy us.   The REST part might be of interest.   Is that enough
reason to install a heavyweight framework?  I dunno, but it seems
worth looking into and evaluating.

>
> Addons can be built using its addon functionality or using REST
> interface. I think this can save a lot of time over a home grown
> framework.

Also might want to revisit the decision not to use Catalyst.  My
discussions with Matt Trout have been interesting in that area, in
particular due to the fact that he has pointed out that many people
are not using ORM's with Catalyst.

Just to give a recap on why we made this decision in the past, the
decision was due to the sense that if we used a framework, there would
be pressure towards moving towards an ORM.  Because we are really
trying to leverage the features of PostgreSQL, an ORM would add
complexity rather than reduce it.  Many of the advanced features I
would like to see in the db layer can be invisibly handled by recent
versions of DBD::Pg (Object -> custom type conversions for example).
Consequently, the idea is that the application/db boundary just isn't
drawn in an ORM-friendly way.

I think what will be required is an actual review of potential
frameworks and what they might actually bring to the table given that
the use of an ORM is most likely out of the question for any code
distributed as part of the project.

Best Wishes,
Chris Travers