Re: Proposal regarding 1.6

[ snip ]

Summarizing most of the discussion:

1. There's a lot we can still do in 1.x, e.g.

a. Better installation experience

b. Better admin tools

c. Disentangle tightly coupled code like 'ship to' and 'e-mail'

d. True multi currency

e. Much, much more QA and automated testing

2. As a mental model, 2.x might help us discover where we can do - even within 1.x

3. Before we can make some of the steps mentioned above, we'll need to have in-depth discussion on the goals and the design, because the low-hanging fruits have largely been reaped

4. The general tool to help disentangling the Perl code *and* to improve user experience seems to be through Dojo/browser-client-side solutions

With respect to the last point, as you know, I'm trying to retrofit a Dojo interface on top of some existing code which I taught to "speak" JSON. My journey shows that this is a far from ideal situation and that it's hard to achieve good results. This experience by itself is enough evidence - I would say (and I hope you do too, when I finally commit the results) - to start working on a service based architecture as soon as 1.5 gets out the door.

At that point we immediatly arrive at point (3): designing a URL space for our services is one of the discussions we still need to have and *that* is exactly the reason I'm working off of the existing code base molding it into something of which Dojo thinks it's a REST service...

I'm thinking of ways forward without loosing focus on actually getting forward. How about listing the topics that we're currently running into and discussing those one-by-one in order of most to least important (blocking work)? It'd be nice if we could store the result of the discussion on the ledgersmb.org site as a policy or design document.

To kick off such a list, I personally have the following issues which need design or an approach discussion:

- Service URL space, most notably dealing with tables which have composite primary keys

- Framework for writing tests for services

- Framework for writing tests for browser-based functionalities

Do you have others?

There was some discussion between the two of us a few months back about cash reporting and the Cashflow Statement though that "simply" marking accounts as "cash related" didn't work.

The problem with the cash flow statement is different. It is because despite the name it is actually an accrual report, but the sectioning is different than what we support. So supporting that report requires additional categorization on accounts.

I was referring to this: http://www.accountingcoach.com/cash-flow-statement/explanation

What I remember is that it *mostly* worked, but the problem came when assets were sold off at their end-of-life. What I remember is that the cash flow of the end-of-life sale is to be reported as gains/losses from investment activities, which was a problem given that the regular movements on the investment section (depreciation) is a loss from operational activities. To understand the true problem again, I/we'll have to go through the entire cycle of creating a mapping of accounts to a cashflow statement again.

Yeah, I think you are thinking of the cash-basis income statement? I suspect things may have different names in different places?

2. We would have much better performance and clearer code if the journal tables were unified or split off in better ways.

Agreed. Although this is a change with widespread consequences in the Perl code, it's a pretty minor change in the sql code, I think (yes, the three tables are union-queried all over the place, but if they are mostly replaced by a single table listing all transactions, many uses of the ar and ap tables can simply be dropped.)

Well, in the end, not addressing with this proposal how and when we get there. I think there are a lot of things to think about such as whether we need to move code anyway onto Dancer, and if we need to do that, what the best way forward on that is. So after our previous conversation I am not sure we are in a place yet to map out exactly what needs to be done to rewrite the financial code. I do however think important steps can be taken in 1.x in this direction.

Ok. I don't know the exact steps either, but one of the things that we *will* need is disentangling contrived code and update paths -- we both agree about that. Probably, when that's done, it'll become much clearer what actually needs to happen.

[ snip violent agreement ]

[ snip about admin tool ]

It also occurs to me that if the admin tool is sufficiently service-oriented, then the installation wizard could be a _javascript_ app bundled with the main program.

There is one limitation that has occurred to me and that is that the current approach returns html in most cases rather than using services and dojo. Although I think we support services for xhr calls, that doesn't do much for things like lwp. If we do a clean service/dojo API though then that goes away. I think getting this right would be a good step towards getting started on other service areas.

Actually, the pricematrix page that I'm now working on returns only minimal HTML: the widgets are all loaded and instantiated by Dojo. This all happens through resource and service URLs, meaning that the "base" URL space will see minimal functionality anymore.

From what I could determine, that's how GitLab (I'm using GitLab for one of the sites I'm an admin of, as you know) seems to work (although I have no idea if it uses Dojo for its widgets).

[ snip more violent agreement ]

Thanks for posting your thoughts and thanks for the discussion. I know we need a lot more of it, but the form that this discussion has taken is a good and effective one, I think.

One of the things that I'm wondering about now though is how to keep it up and jump to the next step, keeping momentum now that we seem to have it?

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.