On Tue, 29 Jan 2008, Chris Travers wrote: > On Jan 29, 2008 8:39 AM, Paul Wrightson <[EMAIL PROTECTED]> wrote: > > > Both of the examples cited here are specific-ish customizations for > > specific-ish businesses. What I mean be "specific-ish" is that the > > functionality does not apply to the majority of businesses, nor just a > > single business, but a sub-set of all businesses. > > > > > > What I believe we need is a framework that allows user-specified > > workflow to be triggered under certain circumstances. For example, a new > > customer added could trigger an external process that checks the billing > > and shipping addresses and also checks an external credit database to > > apply the appropriate credit limit to the account and sends a 'welcome' > > email. Another example could be to automatically build a vendor PO > > whenever inventory falls below the re-order value - triggered by either > > a purchase or by a stocktaking function within LS. > > > That is a good description of the problem. I think the solution involves a > two-dimentional modularization of the software: > 1) Vertical modularization: Stable SB APIs, Workflow scripts, and > templates. This allows people to customize the workflow/UI of the software > relatively easily without having to be Perl gurus or have the QA issues that > currently affect the legacy codebase. All new or re-engineered code > in 1.3follows the above approach. Also the new menu structure allows > one to add > new menu items to custom workflows reasonably easily. > > 2) Horizontal modularization: The current application could be broken down > into: core/financial, inventory, and POS modules. CRM, MRP, etc. modules > could also be written and possibly bundled. This would allow businesses who > don't need some functionality to simply not install it.
One thing that always bugged me, was that the "API" was nothing of the sort. It is simply a browser-free call of the CGI scripts--very breakable, and not very flexible. The solution that has always suggested itself to me, was daemonizing the backend. Provide authenticated access via keys or the like. A real command based API, which any front end--web, GUI, CLI, could be used to access. Yes, I know, I am out of my mind. But to me, that would be the height of modularization. In any case, I like what you are describing. Luke ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
