> On Dec 25, 2017, at 1:01 PM, Lincoln A Baxter <[email protected]> wrote: > > 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.
Except for the RESTful part, yes. MVC separation has been one of the development goals for years. We're severely constrained in developer hours so unfortunately it's likely to be a goal for many years to come. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
