LedgerSMB runtime environments

[David Tangye <..hidden..>]

On Mon, 2006-09-11 at 10:49 -0700, Chris Travers wrote: as thread
"Potential security issue with LedgerSMB (inherited from SL)"

> I think terminal support should be through a separate program with a
> usable interface :-)
Probably, but I would be very wary of including a terminal interface
into the application, because:
 - Users ought to work everything except perhaps upgrades via the
browser, and 
 - Some other developers (script hackers) in future might get carried
away and built a lot of functionality in that will have a rough
interface, but it will force work by yourselves to rewrite/tidy it up
into perl and browser. Its the same as if someone started adding stuff
in in java and someone else in php and someone else in lisp. It would be
tempting to take the code, but I am sure you would prefer or find the
need to spend effort recoding it all in perl.

> And terminal applications should be using Lynx or something similar
> (believe it or not, it works better with SL than Links due to screen
> size and extra key presses). 
I am not sure that any terminal/character interface is needed at all. In
this day and age of the GUI and web browser, I think the best thing to
do is to put all focus on just that one front-end environment. That is
why removing the Oracle and DB2 backend stuff out completely was a good
move. It regains pretty-much unnecessary dissipation of development
resources, and this is a smart move, and something we should always try
to do.

How many application dimensions does SL need to cater for:

1. Back-end data store: Postgres + Oracle + DB2; but only Postgres is
maintained anyway
2. Front-end UI: Mozilla + Lynx + ?
3. Language, but for application to user messages only: as per the
locale directory

Its a great gain to remove the first two entirely from LedgerSMB,
applying the 80/20 rule, or is it 99/05 in the case of Front-end UI?
 - Back-end: SQL to postgres only. Consider code modularity so others
can add complete SQL to xyz at any time in the future that they have the
resources to do it properly and will maintain it. I can see people
wanting a connection to mysql and maybe back to Oracle one day. As a
strategy, I suggest SQL only, consider object-oriented DBMS's beyond the
scope of LedgerSMB: its for text and numbers only.
 - 

Plus there's still the 'constant data' clones that need to be maintained
-
4, 5, 6: css's, templates, charts (BTW: cant the charts and database
upgrade sql files be better separated?)

Plus there is the coding languages: perl, sql, tex to master, before
starting on the complexity of the domain expertise (ie accounting) and
application functional logic. I think the project has enough complexity
as is.

Fragmentation/duplication will lead to diffusion of effort, and hinder
creation and improvement to the application's business functionality.

> Terminal support is a good thing for scripting and automation.  But
> the current approach is bad...
Why not use a standard gui script front end like zenity/gdialog, that as
per that upgradeSqlLedger script I gave you, as a last resort for
anything that might need to be controlled outside of the browser
environment, if anything? Its a half-reasonable workable solution for
that sort of thing.