> On Feb 5, 2024, at 03:40, Kevin Buckley via gnucash-devel
> wrote:
>
> On Monday, February 5th, 2024 at 12:36, john wrote:
>>
>> Those XML changes sound like the wrong direction.
>> XML code needs to stay in libgnucash/backend, not get mixed in with
>> engine/QOF,
>> especially since
It needed more thought and experiment, but isolating data structures to the
individual classes would still be the best way to go if they can be
provided with a simple interface to read and write basic data types to/from
whatever our backend structure(s) would be while hiding those details.
Whether
On Monday, February 5th, 2024 at 12:36, john wrote:
>
> Those XML changes sound like the wrong direction.
> XML code needs to stay in libgnucash/backend, not get mixed in with
> engine/QOF,
> especially since the long-range plan is to turn XML into a backup format
> with SQL being the primary
Those XML changes sound like the wrong direction. XML code needs to stay in
libgnucash/backend, not get mixed in with engine/QOF, especially since the
long-range plan is to turn XML into a backup format with SQL being the primary
storage and data access mechanism.
I understand the reluctance
Great. Thank you for the insights. Before I got overwhelmed with work and
other commitments last year, I was experimenting with a set of base classes
that would replace the lower level qof infrastructure. As part of that, I
was also looking at an alternative xml concept where xml provided some
> On Feb 4, 2024, at 12:11 PM, Brian Rater wrote:
>
> I've been looking at the import code and documentation and I'm wondering
> what the overall plan and path is. It looks like there is a "generic"
> implementation in the top level directory which has utilities that are
> being converted to
