Beyond 2.8 - namespaces

[Aaron Laws]

On Mon, Dec 25, 2017 at 6:26 PM, John Ralls <jralls at ceridwen.us> wrote:

>
>
> > 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
>

I've always assumed (and I think I'm with the development team in this
pattern of thought) that the mechanism of connecting the front and back
ends together would be same-process function calls. That means that if a
"desktop" user and web user both want to interact with gnucash data, there
would be two separate processes involved either both able to see the
database file (in the case of sqlite) or both connecting to the database
(mysql, postgres, etc.), and using synchronization mechanisms at the
database level.

I hadn't thought about creating a client/sever model within gnucash: having
a gnucash server process connected to the data store exposing its own REST
endpoints and clients (web, desktop, mobile, etc.) communicating with that
server process via REST. I don't think it's a good idea, but it's worth
thinking about. It would, of course, require a casual user (single desktop
user with one data file) to have to have a server and client process
running. In general, I think it would be a needless source of complexity
since the earlier approach I mentioned (single-processes communicating with
the database directly) works just fine.

Of course, other problem spaces benefit greatly from this sort of
client/server divide, but that tends to be the case when the client code is
unknown and wildly variable. Think Google maps API where any Joe can write
up a client and needs a generic way to interact with the maps API. I don't
think it's too much burden to expect someone writing a gnucash front end to
have to link to the gnucash engine, and I think this level of flexibility
is not valuable to Gnucash.

That said, as Mr. Ralls mentioned, separation of business logic and GUI
logic is a high-priority development goal, but happens to be a colossal
task in Gnucash.