[ snip ]Summarizing most of the discussion:1. There's a lot we can still do in 1.x, e.g.a. Better installation experienceb. Better admin toolsc. Disentangle tightly coupled code like 'ship to' and 'e-mail'd. True multi currencye. Much, much more QA and automated testing2. As a mental model, 2.x might help us discover where we can do - even within 1.x3. 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 reaped4. 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 functionalitiesDo 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
[ 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.
Ledger-smb-devel mailing list
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel