2006/11/3, Derek Atkins <[EMAIL PROTECTED]>: > Quoting Daniel Espinosa <[EMAIL PROTECTED]>: > > > I'm trying to question in the best way, with out injury to any, the GC > > architecture and try to HELP to have a better one. > > The steps towards a better architecture are: > > 1) Convert QOF to use GObject natively instead of being GObject-like > 2) Using the same QOF APIs, try to use GDA natively inside QOF > 3) Consider moving more information into QOF. > > However, in the short term, major architectural changes aren't on the table.
I'll try to joint to the QOF mailing team and try to help in this issues. > > >> > Using a GdaDataModel or a GdaQuery, you can directly modify the data > >> > in the DataBase using a begin/commit transaction (usefull in a > >> > multiuser enviroment), of course this could fix the *autosave* future > >> > request becouse you can edit a transaction and when saved it wil be > >> > automaticaly commit to the server/database. > >> > >> You're missing a fundamental architectural design of QOF and GnuCash. > >> Please go study QOF and then come back here. > > > > I don't missing that, I have studied the QOF enough to know that is a > > GObject like implementation with a kind of GInterface, where you have > > to implement the methods in order to do the work like (init, dispouse, > > begin transaction, commit, roll back, and so). > > This is true, QOF is gobject-like.... > > > If QOF have a GObject like architecture, may you can create objects > > where you can have methods for the GC to make his work, and allow any > > to derive from them to implement a new characteristics, even if the > > Backend have a GInterface (it has) you can implement the it in order > > to create a new back end a a clear way (I know this way in on the > > QOF's documentation); GDA has this kind of architecture in order to > > allow new Providers (any) implement the API and allow to be used > > inside a GDA app. > > Yes, but it's still just the backend.. The front end isn't changing. > GnuCash is still buffering the data (through QOF). QOF is just a > framework; the objects themselves are still cached in RAM, and implemented > by GnuCash. QOF just provides the framework to hold it all together > and Query over those objects. I have some work about the implementation of GDA using a code from Chis, and yes I'd used QOF and try to implement most of the interfaces, but becouse I don't understand most of GC I couldn't find who to work with the parameters sended when the function is called by GC, even that, I want to finish the definition of the database schema to find out later how to implement in the begin_session function using just GDA. > > But as you can see from other email, I'm open to listen. Chris convinced me > that we should look forward to GDA-2 (through 1.99) instead of keeping > with 1.9 I can help here!, I was working for about 1 year in GDA 1.9x.x development process, basicaly in this areas: - Porting the GdaValue to GValue - Creation of Convenient functions to easy use of GDA - Fix compilations problems for the C# bindings (I'm not a C# programer, just find the way to fix them) - I have a work to make GnomeDB work in Glade3 (mostly finished) - I have to modify some GnomeDB widgets in order to work well in Glade3, and fixed some issues I know some about GObject architecture, I plan to use this to understand QOF, that's the easy part, and plan to implement most of the Interface to create the backend privider independient as far as I could, focus on SQLite for the first time and PosgreSQL in parallel. -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE) _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
