Re: Beyond 2.8 - namespaces

[Aaron Laws]

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

[John Ralls]

> 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

[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




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[John Ralls]

> On Dec 25, 2017, at 9:24 AM, Geert Janssens  
> wrote:
> 
> Op maandag 25 december 2017 17:34:22 CET schreef Christian Stimming:
>> As for the namespace aliases such as "namespace gia =
>> gnc::import::aqbanking", those must not appear in header files, but may
>> appear in cpp files. However, I didn't like those in general, as it makes
>> readability for other people much harder. In terms of mutual readability of
>> code, I would rather stick to the plain namespace names and that's it.
>> 
> Ok. I know we are using them in our new c++ code when referencing certain 
> boost namespaces. And the readability aspect works both ways. If namespaces 
> get too long, the code becomes hard to read as well. I have found my IDE 
> (kdevelop currently) quite helpful in deciphering the aliases. I'm not sure 
> which way I like best currently.

I used them in GncDateTime because the boost::date_time developer got carried 
away in exactly the way I warned against. Those aliases are in a single 
implementation file that’s intended to hide the implementation details from the 
rest of GnuCash.

There’s another use of aliases that does belong in headers: Declaring a 
pseudo-type for container classes. For example, from gnc-backend-sql.hpp:

using VersionPair = std::pair;
using VersionVec = std::vector;

helps express the container’s intended use (a vector of version tags) and is 
much more readable in code than writing std::vector> all over the place.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[Geert Janssens]

Op maandag 25 december 2017 17:34:22 CET schreef Christian Stimming:
> Hi Geert,
> 
> just two bits of thoughts from my side:
> 
> Am Sonntag, 24. Dezember 2017, 17:34:51 schrieb Geert Janssens:
> > 1. Use of namespaces.
> > ... nested namespaces ...
> 
> Yes, absolutely. I have quite some experience with C++ libraries and
> applications and I made very positive experience with this scheme. In our
> case this means we put all of our code in a "gnc::" namespace (at least).
> 
> For me, the nicest way to write this was indeed to wrap the content of every
> file by "namespace gnc {" and "}" (except for the #include directives and
> such). There are some examples - but very few - where some other code
> requires us to put code from us in other namespaces, such as some io
> modifiers, or operators for std classes, but this is then clearly visible.
> 
> Nevertheless "using namespace gnc" should rather not be used, as it makes
> the point of namespaces quite moot, as John already said.
> 
Ok, I can live with this as well.

> Also, if there is some sort of "modules" that are used in some places but
> not everywhere, it is also useful to add another level of sub-namespace.
> Such as "gnc::import::", but maybe not quite the "engine", as it is used
> throughout everywhere of our code anyway.
> 
Agreed, adding an "engine" sub-namespace would not add much.

> If there are any nested namespaces, I would strongly recommend to match the
> namespace structure also in the directory names, at least the topmost ones.
> In our case this implies to match this also in the gnc-modules structure.
> 
Good point.

> Apart from this, and for the project of our size, we might very well not
> need more than two levels of namespaces.
> 
Agreed.

> As for the namespace aliases such as "namespace gia =
> gnc::import::aqbanking", those must not appear in header files, but may
> appear in cpp files. However, I didn't like those in general, as it makes
> readability for other people much harder. In terms of mutual readability of
> code, I would rather stick to the plain namespace names and that's it.
> 
Ok. I know we are using them in our new c++ code when referencing certain 
boost namespaces. And the readability aspect works both ways. If namespaces 
get too long, the code becomes hard to read as well. I have found my IDE 
(kdevelop currently) quite helpful in deciphering the aliases. I'm not sure 
which way I like best currently.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[Geert Janssens]

Op maandag 25 december 2017 00:34:39 CET schreef John Ralls:
> > On Dec 24, 2017, at 8:34 AM, Geert Janssens 
> > wrote:
> > 
> > 2. Versioning.
> > 
> > We currently use a version scheme gigantic.major.minor[-build]. Like
> > 2.6.19
> > (and an optional -2 if we had to release more than once to get it right).
> > For the 3 levels we really only use two. The 2 in front has been updated
> > when gnucash migrated from gtk to gtk2.  We will migrate to gtk3 for
> > gnucash 2.8 yet we don't changed to 3.0 as a result. The migration to
> > gtk2 has been a long time ago and the software world has evolved since
> > then. Release cycles in general have shortened. Incremental changes are
> > usually preferred over big bang changes. So I think our numbering scheme
> > is in for a modernization.
> > 
> > Here's my proposal:
> > After the 2.8 lifecycle let's drop one number and stick with major.minor[-
> > build] instead.
> > Major releases would increment the first number. Bugfix releases the
> > second.
> > 
> > So after 2.8 the next major release would be 3.0, bugfix releases for that
> > major release would become 3.1, 3.2, 3.4...
> > 
> > I would drop the idea of odd numbers being development snapshots and even
> > numbers being stable ones. Instead I see several options, I haven't
> > decided
> > which one is most elegant/kludgy:
> > 
> > Option A: let's number development snapshots starting from x.90. That
> > gives us 10 development snapshots. If that's not enough we can either
> > choose to start a bit earlier, like x.80 or from x.98 jump to x.980 to
> > give us 20 more. Option B: as a variation all development snapshots do
> > use a 3 number version: x.99.z with 99 clearly indicating "right before
> > the next major release" and z incrementing with each snapshot.
> > 
> > This makes development snapshots slightly more verbose in their numbering
> > but gives us cleanly incrementing stable releases. The latter are more
> > visible to most users, so I personally care more about those.
> > 
> > The development snapshots between 2.8 and 3.0 fall a bit in between. We
> > could choose to handle them old style or new style as we see fit. Old
> > style would mean we'd still work with a 2.9.x series. New style would
> > mean we'd start with 2.8.90/2.8.99.1 as we see fit.
> > 
> > Thoughts ?
> 
> I’m indifferent to the versioning system as long as it’s consistent, but the
> distro packagers aren’t. Some of them recite the “Semantic Versioning” [1]
> mantra even though it really applies only to libraries.
> 
Interesting link though it does indeed target mostly libraries. The Stack 
Exchange link [1] Alen Siljak posted in his reply also suggests semantic 
versioning. However at the same time one of the (highly ranked) answers on 
that page does give reasons why applications may choose not to follow this 
scheme.

I've also read the semantic versioning scheme and I think we have been 
ignoring the distinction between minor and micro for a long time and are 
really using their minor number as our major one. We don't really expose an 
api right now, but we allow things like incompatible config file or data file 
changes only in what we call a major release (like 2.6.0, 2.8.0). We don't 
make a distinction between adding smaller features and bugfixes as long as 
they don't break compatibility. So to my mind our versioning would be semantic 
as well, but with one level of detail less.

> Back when we released 2.6 we were unsure about whether the coming version
> would be 2.8 or 3.0. One of the criteria proposed was that we should call
> it 3.0 if we upgraded to Gtk+3. Well, we have, so maybe the coming release
> should be 3.0.0 instead of 2.8.0. That would certainly be consistent with
> the Gnome guidelines [2] that include a major change in the GUI as a reason
> for bumping the major version.

We could, though I'm not really married to Gnome's guidelines. Also I don't 
really follow the idea of big-bang releases. I'm more in favor of steady, 
incremental development. Having a different number for major changes grows 
wrong user expectations (or disappointments if that number is not changed for 
sufficiently long enough). Simply increasing one number just indicates there's 
progress.

> 
> Should some of the component libraries (especially libgnucash) have separate
> versioning that follows the semantic versioning rules?

Now that is an interesting question. Perhaps we should as soon as libgnucash 
is something worth mentioning on its own and I think even then only if we will 
consider releasing them independently.

And regardless I'd still be fine with a two-number scheme as it reflects our 
development practises more closely than a 3-number one.

If we go for separate versioning at some point I'd make gnucash follow the 
major version of libgnucash.

Lastly, while reading the two links you added I found the even/odd distinction 
is not mentioned at all in semantic versioning but instead is an 

Re: Beyond 2.8 - namespaces

[Geert Janssens]

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

Re: Beyond 2.8 - some design thoughts

[Christian Stimming]

Hi Geert,

just two bits of thoughts from my side:

Am Sonntag, 24. Dezember 2017, 17:34:51 schrieb Geert Janssens:
> 1. Use of namespaces.
> ... nested namespaces ...

Yes, absolutely. I have quite some experience with C++ libraries and 
applications and I made very positive experience with this scheme. In our case 
this means we put all of our code in a "gnc::" namespace (at least). 

For me, the nicest way to write this was indeed to wrap the content of every 
file by "namespace gnc {" and "}" (except for the #include directives and 
such). There are some examples - but very few - where some other code requires 
us to put code from us in other namespaces, such as some io modifiers, or 
operators for std classes, but this is then clearly visible. 

Nevertheless "using namespace gnc" should rather not be used, as it makes the 
point of namespaces quite moot, as John already said.

Also, if there is some sort of "modules" that are used in some places but not 
everywhere, it is also useful to add another level of sub-namespace. Such as 
"gnc::import::", but maybe not quite the "engine", as it is used throughout 
everywhere of our code anyway.

If there are any nested namespaces, I would strongly recommend to match the 
namespace structure also in the directory names, at least the topmost ones. In 
our case this implies to match this also in the gnc-modules structure.

Apart from this, and for the project of our size, we might very well not need 
more than two levels of namespaces.

As for the namespace aliases such as "namespace gia = gnc::import::aqbanking", 
those must not appear in header files, but may appear in cpp files. However, I 
didn't like those in general, as it makes readability for other people much 
harder. In terms of mutual readability of code, I would rather stick to the 
plain namespace names and that's it.

> 2. Versioning.
> Here's my proposal:
> After the 2.8 lifecycle let's drop one number and stick with major.minor[-
> build] instead.
> Major releases would increment the first number. Bugfix releases the second.

+1 from me.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel