The source code in our project falls into two categories:
> 1. the code we newly wrote (and which we want to maintain)
> 2. the code that we inherited (and which we want to replace)
> I'm Glad you said "want to replace" rather than "need" here, it's a vital
> distinction that hasn't always been made in the past.
[ snip ]
> The remaining legacy code will get replaced in stages when we have a good
> NEED to start doing so.
That's my idea indeed: rewriting as we go, addressing the 'next step low
hanging fruit' every step on the way. While parts will be harder than
others, I'm thinking our new UI approach which places some responsibilities
on the client, adds the ability to move parts of screens over to a new
approach while other parts may retain the old ("Update"-based) approach.
> Where to find code of the first and the second category, is pretty clear
> to most of us. However, it's not to any new-comers to the project.
> In order to improve this clarity - making it easier to communicate about
> it - I'm proposing to move all *library* code that we intend to replace
> from lib/ to old/, meaning
> * lib/LedgerSMB/??.pm -> old/LedgerSMB/??.pm
> * lib/LedgerSMB/PriceMatrix.pm -> old/LedgerSMB/
> * lib/LedgerSMB/Form.pm -> old/LedgerSMB/
> * lib/LedgerSMB/Num2text.pm -> old/LedgerSMB/
> * lib/LedgerSMB/Session.pm -> old/LedgerSMB/
> * lib/LedgerSMB/old_code.pm -> old/LedgerSMB/
> * lib/LedgerSMB/PGOld.pm -> old/LedgerSMB/
> While I'm aware we didn't inherit PGOld, but I think it's code we want to
> phase out anyway.I'd go one step further, and actually use,
> * lib/LedgerSMB/$legacy_files -> old/lib/
> * bin/* -> old/bin
This thought *did* cross my mind, but I rejected it at the time.
> This allows us to start getting some support scripts that a sysadmin would
> normally expect to find in a bin dir where they belong.
Ok. That's a compelling reason. My prior hesitation was because the path to
'bin/' as the location of the "old code scripts" is coded all over the
place. On the other hand, it should be trivially fixable to find these
occurrences and replace them by old/bin/...
> Things like create a new company (from the command line), and possibly
> scripts for direct import of data, upgrading a src install, verifying that
> dependencies are correctly installed, who knows what else we may want.
> Furher more, I'd like to remove the REST_Class::* and REST_Format::*
> handlers, as they apply to REST services which we never really supported.
> I'm happy to drop the REST handlers, especially in light of the Plan we
> came up with when I met up with you while I was in Europe.
Ok. As to the services plan we have, I'll wait to delete the REST handlers
for us to have written down our first service API documentation/approach.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Ledger-smb-devel mailing list