Beyond 2.8 - namespaces

[Lincoln A Baxter]

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