On Mon, Jul 20, 2009 at 2:46 PM, John Locke <[email protected]> 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 <[email protected]>
> To: Development discussion for LedgerSMB
> <[email protected]>
> 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?
>
> I'd vote for a single call interface, over multiple top-level scripts,
> 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
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
