On Mon, 2017-12-25 at 17:34 +0100, Geert Janssens wrote: > Agreed indeed. For example in my work on the importers I have > introduced a > strict separation of import functionality and gui. So the non-gui > parts of the > importer should move to libgnucash eventually as I want them to > bepart of the > api. That way they can be used by other applications (mobile apps, > web > app,...) and would be available to the bindings as well.
First, let me say, I have been using GC since at least 2005, and I've only recently begun following the dev list. That said, I have a lot of experience in application/solution and n-tier client/server architectures at the corporate level... so please take this as just something to consider... As I was reading this thread, and thinking about this C++ refactoring, a question occurred to me, which a little bit relates to Geert's above quoted paragraph. Has anyone thought about separating the UI functionality from application functionality using a (restful) services interface between the GUI and the "library" (application logic)? The interface to the library would not have to be implemented as services (initially), but if it were thought of this way, one might be able to separate out UI functionality from application functionality pretty completely... eventually anyway. Might this be a way to eventually move to a multiuser environment, which comes up not infrequently on the user list? With this approach, the "server side" could still keep the entire model in memory. If so, I would think this might influence what goes into libgnucash? I suspect this approach could eventually help facilitating multiple front-side UI's but common logic on the back-side I think this would allow one to eventually move to a browser based UI. One would not have to go "all the way" initially, but if this were a paradigm for choosing what goes where, GC would be able to migrate to such an architecture over time. Just a thought, FWIW. Lincoln _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
