On Mon, Jul 20, 2009 at 2:46 PM, John Locke
<..hidden..> wrote:
HI, Chris,
I haven't had a chance to try out much of 1.3 since the recent
milestones--I look forward to checking out the progress and see how it's
going! And also to contributing more sometime soon. Some of the changes
below would make it easier for me to contribute, others harder...
-------- Original Message --------
Subject: [Ledger-smb-devel] RFC: Proposed Framework Change for 1.4
From: Chris Travers <
..hidden..>
To: Development discussion for LedgerSMB
<
..hidden..>
Date: Mon 20 Jul 2009 02:00:08 PM PDT
> Hi all;
>
> While the 1.3 framework is a great improvement on the 1.2 framework, I
> have noticed a number of things that I think should be changed, as
> well as a few new opportunities to simplify things in 1.4.
>
> First, I would like to propose that 1.4 be targetted at PostgreSQL 8.4
> or higher, and require whatever DBD::Pg modules are current at the
> time when 1.3 is released (i.e. the time when we begin serious work on
> 1.4). LedgerSMB 1.3 would remain supported for a number of years
> after release (at least 3) so this shouldn't cause any real headaches
> in terms of forcing folks to upgrade..... 8.4 would also allow us to
> do away with the dependency on tablefunc for the menus and move to
> WITH RECURSIVE instead, and it would allow a number of other things
> that could be used to better enforce data integrity between the app
> and the db.
>
This is probably the biggest reason I haven't yet extensively tested out
1.3 -- because my production servers running postgres have been 8.1, and
we try to keep our development environments as close to possible to
production.
1.3 requires Pg 8.1 or higher (8.1 for the role system). I am doing all my devel on 8.1. Others are using 8.2 or 8.3. Nobody I know iof is using 8.4 but I don't think it would be a problem. You are probably confusing the desire to make 1.4 dependant on 8.3 (which I am suggesting updating to 8.4).
Note though that the major issues with 8.3 vs 8.4 are matters of external dependencies. We can reduce the dependencies by going to 8.4. And the windowing functions would be helpful as well, as we move forward. This would result in better simplicity in the code as well. 8.3 gives us 90% of the new features we need, and it wouldn't be the end of the world if we have to support 8.3 or higher, but I think the quality of code would benefit.
We have now moved over to a server with 8.3, just last week in fact. So
I expect to be able to start testing 1.3 shortly.
Adding a limitation of 8.4 would mean I'd need to set up an entirely new
environment to do anything with 1.4. Since we try to keep our dev
servers somewhat synchronized with production, it's hard for me to keep
up with bleeding-edge database releases.
The areas where 8.4 is a clear winner is in the areas of tree structure generation and windowing functions. This allows for easier running totals in the database procedures, etc.
Now, one mitigating factor is that several modules in 1.4 will probably start out as add-ins for 1.3. These will involve fixed asset modules, transaction templates, and a basic MRP module. I would suggest that we get these developed and solid before we start working hard on 1.4. This also gives us some time to decide how important it really is to use windowing functions (and if we avoid them, having to rewrite the same functions in the next version).
So I'd prefer seeing backwards compatibility for the database supporting
8.3 or newer. 8.4 is probably fine for a full 2.0 release, but it's a
hardship for now--I don't even see any packages available for current
Ubuntu systems, let alone Long Term Support. And I don't see any Debian
packages either. Given that we just upgraded our production
environments, it's probably a couple years before we'd want to do that
again and would even be capable of running 1.4, if it depended on
Postgres 8.4.
Noted. Let me suggest this topic be put on hold until 1.3 is released and we can re-assess. We have a lot of work on 1.4 that can use either 8.3 and 8.4 so we might as well defer a decision until we have to make one....
Then we can balance the question of reporting and tree code (of 8.4) vs. the necessity to phase out LedgerSMB 1.2 support. (Dropping the Pg version would cut a year off our supported life of that software which might be a good thing).
> Anyway, here are my other areas I would like to see addressed:
> 1) The current system presents hazards of customization. One option
> ot address these is to implement a before/instead/after structure and
> move UI template rendering out of the workflow script.
>
Yes! The current scripts seem awkward. I'd like to see more separation,
and an easy way to switch between loading a template and loading an
equivalent view of an object, either as JSON or XML (or other formats,
too). I'd like to see a template system that is loaded after the main
request is processed, that has objects that expose methods for loading
additional data.
In general, looking for more standard ways of calling LSMB from other
programs, and more ability to customize templates in some way that I can
keep those changes outside core. Haven't done a lot of this to know
whether the template system already does what I'm looking for--it
probably does, from the last time I looked at it, but I was having to
add my own data services...
You would probably have to symlink in an "add-ons" directory or similar and then use the path in the template to access it.
> 2) Workflow scripts should be moved to LedgerSMB/Scripts/
>
doesn't matter to me
> 3) Dialog: Do we want to continue having top-level scripts past
> 2.0? I know this has been a point of criticism in the past. However,
> it is something that will probably have to be changed around 2.0.
> What do folks think? What should be the ideal call interface? Maybe
>
http://host/ledger-smb/request.pl?module=journal or something like that?
with parameters as you've shown. I've found having a module, action, and
view parameter for every call, with defaults, to be quite effective.
It's very easy to debug/enhance web service calls when you can switch
between an html template, a json object, or an xml file with a simple
parameter change.
I've also found some of the REST conventions of using http methods for
DELETE and PUT in addition to GET and POST to be very useful.
If we have a single call interface, we should be able to use apache directory handlers to handle REST conventions to a higher degree too.
>
> 4) Our object structure in 1.3 is better than that in 1.2 but it
> still has some serious shortcomings. The biggest one is that the
> modules are still grouped in functional units. This means that object
> properties are not entirely consistent across uses of the same object,
> which makes documentation and tracing a bit difficult. Fixing this
> will require refactoring. I would like to have this refactored into a
> properly documented and designed object oriented framework.
Sounds great. I hope to be able to assist with such a refactoring project...
>
> 5) I would like to revisit a few elements of the database interface
> calls as well. In particular, the latest DBD::Pg and PostgreSQL allow
> us to easily make use of more complex db-side datatypes. If we go
> this route, we should be able to define our data structures in the db,
> as complex types, and build database requests out of it. We could
> also allow primary object attributes to be defined this way, while
> secondary arguments could be defined in a way to allow explicit
> function calls.
I'd like to see this level of functionality available through http and
in whatever templating system is in use. I don't really care whether
these are implemented in Perl or in Postgres -- though as I already
mentioned, requiring the latest Postgres does put a barrier up for my
participation...
Are you looking for RESTful web service interfaces? Sure, we would welcome help with that :-).
>
> What do folks think about these proposals? Anything else that needs
> to be added? Anything that should be up for discussion?
Overall, sounds like a good direction to me! But I think you should
reconsider the database version requirements.
It's one thing to be a showcase application for cutting edge Postgres
releases. But this is an accounting application we're talking about--we
shouldn't be requiring server software that isn't anywhere near any
production distribution releases--you're greatly limiting the potential
audience of users, as well as possible contributors. I think it's fine
to say new development branches require at least as new a Postgres
version as is available in the most current long-term support release of
the major enterprise distributions -- Red Hat, SuSE, Debian, and yes I
do include Ubuntu -- but newer than that is going to really limit
participation. In my opinion, anyway.
Well the tradeoffs for dependng on 8.3 are:
Pro:
1) More users can use the software immediately and more contributors can be involved now
2) Reduces support life for LSMB 1.3
Con:
1) Some parts of the app would do better to be rewritten once we depend on 8.4. Do we want to rewrite an extra time?
2) Extra dependency (tablefunc) that would be eliminated in 8.4.
We can come back to this later. LMB 1.4 will be a big release (probably as ambitious as 1.3). I would hope that 80% of the project could be done as add-ons to 1.3 first, but we will see.
Best Wishes,
Chris Travers