Diverging applications

[David Tangye <..hidden..>]

On Tue, 2006-09-12 at 09:19 -0400, Christopher Murtagh wrote Re:
[Ledger-smb-devel] Proposed file structure changes:
> Greetings folks,
> 
>  Chris and I have been talking about a plan to clean up the code
> structure....

On Tue, 2006-09-12 at 13:12 -0700, Chris Travers wrote Re:
[Ledger-smb-devel] Any objections to including the database schema
unique id patch?:
> 
> I sent yesterday a sql script that will patch the database schema to
> ensure unique transaction id's.  Is there any objection to adding this
> to the next release?
> 
Your ideas sound generally excellent to me. At this stage of embrionic
development of LedgerSMB, it only a question of strategy, and what I
thought would happen, is happening: LedgerSMB is quickly diverging from
SL.

I see no problem with this. Its only a question of realising this, and
planning etc accordingly.

Eg: with the still limited resources that we have, consider the
decreasing likelihood of not being able to keep a migration option into
LSMB, let alone reversing it. In fact forget reversing it as of now?

I think that the best way forward is to be sufficiently confident to
diverge. There is little point in just being SL with its data schema and
a few patches and add-ons on the side. To get a more robust and flexible
application you need a better more robust data schema anyway.

> on within the same file. (all files except for menu.pl are identical
> in bin/mozilla and bin/lynx).
See my upgradeSqlLedger.conf (last **2** lines):
menu.pl = am.pl ap.pl ar.pl bp.pl ca.pl cp.pl ct.pl gl.pl hr.pl ic.pl
ir.pl is.pl jc.pl oe.pl pe.pl ps.pl rc.pl rp.pl

Plus
login.pl = admin.pl

These are in the root directory though. The .pl scripts in bin/mozilla
are all different files. Furthermore some files in the root and
bin/mozilla have the same names, but they are not clones of the same
file. I dont know more than that, just stating what is obvious to me. It
**looks** like a hackers mess, but there will be historic reasons for
it, even if the reasons are irrelevant today.

It sounds like you have far more insight into this than I.

Good luck. 

My view of SLMB right now is :Go for it, change as much as you want. No
pain no gain right now. If anything breaks it should be relatively easy
to fix while few if any production systems are on it - I know mine are
not yet. Its probably worthwhile knowing when anyone starts putting true
production master data onto it (not production-image/-clone/-test) and
until then, go like hell and hack away while not constrained.

> 
>  For custom scripts, I will create a custom directory, and provide an
> upgrade script from the current setup to the new one. Custom scripts
> are currently of the form 'bin/mozilla/custom_am.pl', and will become
> 'custom/am.pl'.
User installed 'plugins' of some type, eg custom shell? perl? scripts
are certainly something that should be catered for. I am thinking about
what types there might be, eg types based on -

 - when invoked: from the install, eg included as pre- and post- scripts
in .deb/.rpm; and also at login, from a user-creatable menu fragment
within the current menu.
 - visible and runnable by whom: per installation, per dataset, per
user. This can probably be implemented on simply a per user basis, as
you have suggested.
 - language (shell,perl) - probably trivial issue, and either can run
SQL for power users.


> 
>  For user based custom scripts, they will also go into the custom
> directory, and simply be called 'username_am.pl'.
Would (LSMB)/users/bin/ be a logical directory? Hmmm, or to allow for
event-driven per user scripts (LSMB)/users/(username)/bin/ where scripts
are named (event).pl etc

> 
>  The result of this cleanup is far fewer files (many of which are
> dupes of each other), fewer hits to the file system for every page
> load, and a simpler, clearer setup.
This will certainly help a lot with team-based development in future.

The best scheme will probably not be apparent until the scope of the
application is defined, and architecture/design defined based on that,
ie a bit more top-down development, rather than bottom-up.

> The only script that poses any sort of problem (and it's actually
> trivial to solve) is the menu.pl script which is different in
> bin/mozilla and bin/lynx. This will simply have a big
> if('lynx'){..}else{} for the moment, but will probably get cleaned up
> and re-org'd later as well.
That's fine. That sort of thing can be data driven.