> On Aug 8, 2022, at 11:04 AM, Robert Simmons <rsimmo...@gmail.com> wrote:
>
> Another observation: the current GnuCash mixes data and display layers.
>
> For a new system, I would suggest separating everything completely. Have a
> database and lib layer that interacts with the database. Then expose the
> lib to C, Python, C++, Rust, Go, whatever. You can then have a REST layer
> built on one of those. Then a GTK display layer (what GnuCash is now) would
> be built against the API. And a web layer can be built against the REST API.
Yes, we know about GnuCash's spaghetti problem, we deal with it daily. Fixing
it is on the list.
Keep in mind that we're not starting from scratch. GnuCash version N has to
work with data from version N-1 and version N-1.last has to be able to load a
version N file. We have to develop version N while still maintaining version
N-1 with quarterly releases. The only way to make that happen is incremental
change. Also keep in mind that GnuCash is an all-volunteer project maintained
and developed by a very small group. Progress is guaranteed to be much slower
than anyone would like.
As for a REST API, I don't think there's a viable use-case that's compatible
with FOSS, but the fact that it might be possible suggests that we should
consider changing the license to GPL-Affero to preclude someone using GnuCash
in a non-Free software-as-a-service scheme.
Regards,
John Ralls
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
