On Sun, Mar 7, 2010 at 4:18 PM, David F. Skoll <[email protected]> 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
