Beyond 2.8 - namespaces

[John Ralls]

> On Dec 25, 2017, at 1:01 PM, Lincoln A Baxter <lab at lincolnbaxter.com> 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