Re: Beyond 2.8 - namespaces
Aaron Laws writes: [snip] > 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. In the single-user/desktop case, the application can spawn the server sub-process if it's not already running, and the server sub-process can exit when it has no connections. [snip] > 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. Agreed. A true MVC with complete disconnection of business logic means a less-usage UI. You want the UI to be able to inform the user as soon as possible that there is an "error" in their input. On the other hand, you want that error-checking to be done in a way that *ANY* UI can leverage it (e.g. is my split transaction balanced?). There-in lies the difficulty and challenges, because different UIs are going to want to do that checking in different ways. For example, on a webui you would want to have that checking done in Javascript, whereas the Gtk frontend would want a C/C++ function call. If everything is REST (or REST-like) then you MAY be able to perform intermediary "validate" calls somewhere along the way to provide more real-time feedback. You may not want to wait until the end to perform the validation. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.8 - namespaces
On Mon, Dec 25, 2017 at 6:26 PM, John Ralls wrote: > > > > On Dec 25, 2017, at 1:01 PM, Lincoln A Baxter > 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. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.8 - namespaces
> On Dec 25, 2017, at 1:01 PM, Lincoln A Baxter 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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.8 - namespaces
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
Re: Beyond 2.8 - namespaces
Op maandag 25 december 2017 00:34:39 CET schreef John Ralls:
> > On Dec 24, 2017, at 8:34 AM, Geert Janssens
> > wrote:
> > We can debate whether our internal code can/should have "namespace gnc;"
> > in
> > headers only or in source files as well. For libgnucash I'd go for the
> > latter. It The context should be clear there. In the gnucash gui related
> > code (the parts that are C++ obviously), I would as well, though I have a
> > less strong opinion there.
>
> I don’t think you meant what you said there because I know that you know
> that once you declare something in a namespace you have to either refer to
> it with the namespace qualifier everywhere or alias it in to the scope’s
> namespace with ‘using’.
>
Yes, what I wrote is pretty confusing and in hindsight convoluted as well. I
was mostly considering whether we'd use
namespace gnc
{
...
}
in both header and source files or whether we'd only use that construct in the
header file and explicitly prefix the definitions and calls with gnc:: in the
source files (to maintain namespace protection there).
I'm not even sure the latter would be allowed so I think only the first would
make sense in libgnucash, applying
namespace gnc
{
...
}
in both header and source files.
> Perhaps you mean that you’re not sure if compilation-unit-local functions
> and variables (those typically declared static in C) should also be in the
> gnc namespace. I don’t think so. There’s a special compilation-unit-local
> namespace called the anonymous namespace for that.
>
That's clear.
> Should the gnc namespace be applied to classes throughout the application or
> just to libgnucash classes? I’m inclined to think the latter. The
> application itself doesn’t really benefit from a namespace though some of
> its modules might.
My limited namepaces experience shines through here... I re-read a bit about
it and agree. We should only apply the gnc namespace in libgnucash and not to
classes in the rest of the application. I was really thinking of using the
"using namespace gnc;" directive in the rest of the application. I consider it
reasonable for the application that's really built around the library to do
without the namespace protection for that library.
Using namespaces in the libgnucash allows other consumers the freedom to
choose whether or not they want the namespace protection, similar to how we
can choose this for std:: or boost:: namespaces. Personally I would not drop
the namespace protection for libraries not maintained in the same project
though. If the namespaces get too long, we can go with carefully chosen
aliases (something to find a consistent rule for as well).
> Your division of the code into libgnucash and gnucash is
> a first good cut but I’m sure we agree that it’s going to need refining in
> the next development cycle. Working out namespace divisions can help with
> that refinement because the namespaces will make logical groupings more
> apparent.
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. I can't do this yet
because this separation is only done for the code I touched (the csv
importer). That code is still embedded in a larger import framework which
does not (yet) have this separation.
My inclination to use namespaces for the importer should have been a good hint
it really belongs in libgnucash, but I didn't realize than when I wrote the
proposal :)
In all I'm happy you agree on using namespaces in general. That's enough for
now. We can indeed work out a more detailed hierarchy when we're done with
2.8.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
