2007/6/26, Christian Stimming <[EMAIL PROTECTED]>: > Quoting Martin Kaffanke <[EMAIL PROTECTED]>: > >> Well, it would require work to integrate into gnome-session, get the > >> icon, do the hide vs. exit, and handle graceful shutdown.. But I think > >> this would be much easier than what you propose, and I think it gets > >> you most of what you want (quick 'startup' of the gnucash application). > > > > Yes, but what I suppose with a gnucash-data-server: Gnucash could be > > easyer made multiuser frendly. > > Dear Martin, > > I'd like to remind you of the start of this discussion. Your initial > questions were "Where can I start? Would this be easy on the gnucash > side," and we've answered that. We've pointed out those possibilities > that we consider "easy on the gnucash side". Other possibilities exist > but are definitely not easy.
I have worked in a way to suggest some possibilities about *Change some Things about GnuCash internals*, as Dereck said "The GDA backend will solve most of that particular problem", but I want to work around to have a different backend system but use GDA directly not behind QOF witch limit the GDA's functionality. But becouse fail, I have suggested to allow both libraries work together using GInterface. Why? 1) The user will define where she/he wants to store its data, in a single user XML file or multiuser database server. The multiuser could be "Multiapplication" enviroment. 2) You can allow others like applets to access the GC's data using a database server, witch allows you to have multiple simultaneos access. The data integrity must be ensure by GC, the user (the applet) will call a function: i.e. gnc_add_transaction, this will connect to the database server and updates the required tables to do the job, no GC itselft need to start becouse the app will use a GC library. When database server is used the GDA engine will work on. I know the unswer from Dereck "QOF is better, and GDA will be used just a Backend in QOF", but that is becouse don't know enough about GDA to *see* the advantages to have: 1) Use lot of Dataservers (PostgreSQL, MySQL, SQLite, MS SQL, Oracle and others) 2) Multiuser(app) enviroment 3) Powerfull Queries For more information see http://www.gnome-db.org/DetailledLibgdaFeatures > > Your current statement rather goes towards "I don't like the way > gnucash works currently; can we change it to xyz", and, as you might > guess, this is answered by > http://wiki.gnucash.org/wiki/FAQ#Q:_Why_don.27t_you_rewrite_GnuCash_in_programming_language_xyz_so_that_I_can_contribute_easily.3F > If we can do the following: 1) Work on the GC's engine library to export an API to access the GC's data and/or objects. Actualy this library exist but can't be used becouse doesn't exist a .pc file to create an app to compile against it. This is mostly done. 2) Work to have a multiuser(app) enviroment. This could be achieved by having a backend system wich allows to have XML (actual format) or multiuser concurrent database system. This could be achieved by the GDA backend using the QOF system, but will limit the reatures in GDA. A suggest is to have a GInterface implemented by two or more backend systems. This could be called GncBook, and could allows to insert/update/delete data fed by the backend system in use, with an unique API. Becouse the user will select the backend at "save" time, the object returned at object creation will be, for example, a GDA derived for database system or QOF derived for XML files. The engine's API, will allow other apps (applets for example) to access the GC's data with out run GC at all, just compile against this API and the program could connect to the data storage and insert/update/delete/filter data. GDA allows to create objects implementing GdaDataModel and with that, use a GdaQuery (with all its power) to alter or filter it. This GInterface could be implemented by QofCollection (I'm testing its port to GObject), and with that we can use GdaQuery inmediatly using the QOF system. -- 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