Re: Clearly setting apart the code we want to replace?

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.

--

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.