GObject in GC implementation Plan

[Derek Atkins]

"Daniel Espinosa" <esodan at gmail.com> writes:

>> Well, it's a lot less than what you did..  And the tree continues to
>> work build and actually work.  THAT was the goal for step 1.  Get the
>> initialization moved over and GET IT WORKING.  Your branch still
>> doesn't compile, let alone work.  The reason it fails: you tried to do
>> too much at once.  Not only did you move the base initialization, you
>> tried to move the init/dispose/finalize code and add properties all at
>> once, instead of doing each step separately.
>>
>
> That's why I started a new branch.

Sure, but branches are cheap.  I'd rather have 10 branches
that each get merged in after a week or two than a single
branch that has so many changes that merging takes a month.
Moreover, your commits were all huge.  Take a look at e.g.
http://svn.gnucash.org/trac/changeset/15778 for an example of
a small commit.  Even a single-functional-change changeset like
http://svn.gnucash.org/trac/changeset/15773 is probably too big,
but at least it's limited to a single functional change.

Your commits were all huge (more like 15773 than 15778) AND
multi-functional...  Making them hard to audit.

Moreover, you were doing way too much at once.  You were making too
many functional changes at one time, what with QofEntity->QofInstance,
GObjectification, properties, signals, and changing the Qof type
system all at once...  Too much together.

Branches are cheap.  Let's make separate branches for each of the
"major" functional changes, and keep them to ONLY those functional
changes.

[snip]
> I can understand why you feel that; the reason is that I don't think
> that convert QOF to GObject will be a good idea because its
> implementation doesn't allow it, you'll never have a full GObject
> system if you insist to use QOF.

Well, I don't think it's neccessarily a problem if we don't
have a full GObject system.  We do want to use the features
of GObject that make sense, but there's no reason to use them
just because they exist.

[snip]
> Have you merged with trunk? I want to test a build, see the code and
> help when needed.

Yes, I merged gobject-engine-dev-warlord into trunk in r15846 on April 7.

[snip]
> Phil is creating a backend, using QOF as is.

Correct.

> Maybe GnuCash doesn't need GDA at all, except for a backend, but if
> you want to access the data in GC you have a library, called actually
> Engine, but if we can create an "standard" interface using GDA, this
> will allow:

I think your first sentence hits it on the head.  I don't think
GnuCash needs GDA at all, except for a backend.

Gnucash HAS a data access library, the Engine, and anyone could use
that to access the GnuCash data.

> - Get access from Gnumeric, to create powerfull analisys of the data

Nobody has asked for this.

> - Data interchange with other applications

Okay, there has been some call for this, but we dont need GDA for it.
We can do this as-is using the existing APIs.

> - Import and export data using a CVS file, XML (like QSF does), in a
> standard way (some other software are using GDA today)

I presume you mean "CSV" and not "CVS"..  "Comma Separated Values".
Again, I dont think we need GDA specifically for this, and even
if we did want to use GDA, just having a GDA Backend is sufficient
to do this.

> - Easy data insert/update from other applications, like applets

Nobody has asked for this, and I dont see a major value in this.
Besides, an applet could still just call the current GnuCash API
to perform this functionality.  There's no need to use GDA for this.

> Of course that the GDA interface *must* use all the GC procedures to
> ensure the data integrity and consistency.

Or the other way around...  Plugging in GDA UNDER gnucash as opposed
to putting GDA on top.

Yes, GDA is a cool hammer.  But gnucash is a screw, not a nail.

-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
       warlord at MIT.EDU                        PGP key available