Re: RoadMap Question

[Luke <..hidden..>]

On Tue, 29 Jan 2008, Chris Travers wrote:

> On Jan 29, 2008 8:39 AM, Paul Wrightson <..hidden..> 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