[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal regarding 1.6



Hi Erik;

On Sun, Oct 11, 2015 at 11:35 PM, Erik Huelsmann <..hidden..> wrote:
 
I have been thinking a bit regarding ways forward.  In particular the financial rewrite never seems to go the way I would like it to.

We spoke a bit about this over PM last week. Maybe we can use this (or a new) thread to define what it means to you? I'm not really clear on what the term "financial rewrite" really means to you. Although I do have ideas about breaking down the scope of rewriting the remaining SQL Ledger code into a larger number of smaller rewrites. Before we can do that, though, I think we have a number of areas where we should put requirements/design/workflow in place. I'm thinking about things like these:

Long run for the financial rewrite we need a few things:

1.  Payments need to be first-class transactions.
2.  We would have much better performance and clearer code if the journal tables were unified or split off in better ways.

So that means getting off the current SQL-Ledger perl code and db design.

- Document workflow: Create -> Save -> [ Edit -> Return to Save ] -> Post -> Reproduce [ -> Copy to new ] [ -> Schedule ]
- Rounding
- Subcent prices on anything that's not in the ledger (parts prices?)

stuff like that.

Well, parts and manufacturing can be done in place I think.

We have at least one important feature slated for 1.6, and that is the multi-currency improvements Erik has been working on.  I would like to suggest we do one other thing as well, namely finish App::LedgerSMB::Admin and App::LedgerSMB::Admin::Web, and use these to replace the current setup.pl.

It's my understanding that these will serve a much broader range of functionalities than setup.pl, am I correct? More like a toolset for managing companies within a PostgreSQL cluster (i.e. multiple databases)? Is there anything more to say about it than that?

Agreed generally.  My view is though:  removing Setup.pl and making sure the new admin tool is well integrated gives us some experience integrating Dancer apps with the main application.  This is something we will need experience with going forward anyway, and I am also helping that a good, purpose built admin tool will help to some extent with our setup and installation difficulties.

Work that is left to do here is to add a setup wizard and add user management functions to the web interface.  A major advantage would be an ability to manage multiple LedgerSMB instances from one console, better command line management, and restful interfaces for core administrative functions.

Also, version 1.x of the admin interface uses jquery and templates in a fairly old-fashioned way.  We may want to move to dojo there and start a 2.x branch of this.

Sounds good, but I think that creating services early on allows easier dojoification, because Dojo applications typically benefit from a well structured service infrastructure on the server. Having a full-scale web app based on templates before going Dojo will be a lot of effort wasted on the 'traditional' webapp.

Service are largely supported already in the admin tool, iirc, especially for things like backup and restore.  And moving the rest to services and dojo here is extremely easy (even trivial).

If we want to go with Dancer as an http and web services framework, I think this would be the first step.

That would allow us to remove

LedgerSMB::Darabase
LdgerSMB::Scripts::setup
and maybe a little more.

Removal is generally good. There's one important question though: should we move these into our tree or not? As we factorize many components, it might become harder for people to install the factored-out dependencies. While this may or may not be the case, I think it's something to think about long and hard before we throw up road blocks to installing LedgerSMB.

Agreed generally.  Again part of what I am hoping is that if we do this well, it will help with those roadblocks and at least give us a path forward on solving them.

I would also like to suggest we look closely at one of the following areas (would be interested in hearing where folks largest frustrations are here) in terms of UX, web services, and the like:

chart of accounts, or contact management.

Any thoughts on prioritiing these?

If I can have a vote: Please start with services for contact management. That'll allow easier Dojoification of the contact management screens, which hopefully will help with the clarification of them.

So maybe we should prioritize for 1..6:

1)  Integration of dancer apps (probably the new Admin tool)
2)  Installation and loading.
3)  Contact management (if the other two go well, maybe another dancer app with a dojo front-end?)

Since you bring up installation above, I am wondering if it would make sense, since Dancer apps can run entirely locally on a non-privileged port, to have a web interface that installs all Perl dependencies to a local directory?

The contact management code, even rewritten twice by me is badly structured and would be much nicer if we could split it off into services, so that is indeed where I think we should start.



 

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

------------------------------------------------------------------------------

_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel