On Fri, 2006-11-03 at 12:26 -0600, Daniel Espinosa wrote: > I see you don't want to help any one that doesn't have a previous > knowlege about QOF, even if he/she have some knowlege about GObject > architecture; I know that may you haven't time enough but I haven't > time to learn QOF, I prefer to learn more about GObject.
GObject's great and all, but you can't refuse to understand QOF. It's core to the gnucash engine and backend implementation, for better or for worse. You can't just pretend it's doesn't exist. > Is QOF the realy unique way to solve the GC's objectives? Can't be > moved out or GC must use it in order to work with databases? Abstracty, no. And QOF should probably become a layer over GObject at some point, rather than (effectively) re-implementing parts of it. Keep in mind that QOF started at a time before GObject existed, let alone was accepted and popular... But that's not really the point: GnuCash *is* implemented in terms of QOF, right now. As such, the DB backend is best achieved by working within that framework. (Or put off entirely while GnuCash is re-written in terms of GObject plus a re-tooled QOF.) -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel