Re: Questions about gnuCash backend access
Quoting Samuel deHuszar Allen <[EMAIL PROTECTED]>: > I am a Lotus Notes / web developer. Have built a custom Notes app for > invoicing and billing and am wondering if there is a programmatic way to > create transactions and records in gnuCash. If so, what languages/tools are > needed to talk to the program? There is a C API and a Scheme API. >I am also curious how transactions are > stored internally. XML? Nah, XML is just a storage mechanism. Internally it's stored in a QOF dataset. > Ideally, I would like to create a connection that > would allow either the Domino server, or a server agnostic webservice to > write and retrieve information from mobile devices/web forms. > > Any information to these ends would be greatly appreciated. And to be sure, > any webservice bridge I cobble together will be made available to the > public. :) > > My normal business email is [EMAIL PROTECTED], but we've had some > storms in the Chicago area and my mail server is out until the power comes > back up. Please respond to [EMAIL PROTECTED] > > Thanks in advance, > Samuel deHuszar Allen > [EMAIL PROTECTED] > 773.793.0604 -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
2007/8/24, Samuel deHuszar Allen <[EMAIL PROTECTED]>: > I am a Lotus Notes / web developer. Have built a custom Notes app for > invoicing and billing and am wondering if there is a programmatic way to > create transactions and records in gnuCash. If so, what languages/tools are > needed to talk to the program? I am also curious how transactions are > stored internally. XML? Ideally, I would like to create a connection that > would allow either the Domino server, or a server agnostic webservice to > write and retrieve information from mobile devices/web forms. > For thease reason and others in the mailing list (one about to have an applet), is realy important to allow simultaneous multiaccess to the GnuCash data. Allowing other apps to use a library to connect to the data for consult or modify, without need to run ANY GUI is one of the best solution. I think the use of a GDA based interface could be usefull, any could create powerfull (near to the standard SQL instructions) queries for insert, update or delete, using GdaQuery, connect to the database backend using GdaDict. This library *must* ensure the data integrity and, I think, works as a layer between the applications and GC's data. > Any information to these ends would be greatly appreciated. And to be sure, > any webservice bridge I cobble together will be made available to the > public. :) > > My normal business email is [EMAIL PROTECTED], but we've had some > storms in the Chicago area and my mail server is out until the power comes > back up. Please respond to [EMAIL PROTECTED] > > Thanks in advance, > Samuel deHuszar Allen > [EMAIL PROTECTED] > 773.793.0604 > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- 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
Re: Questions about gnuCash backend access
Quoting Daniel Espinosa <[EMAIL PROTECTED]>: > 2007/8/24, Samuel deHuszar Allen <[EMAIL PROTECTED]>: >> I am a Lotus Notes / web developer. Have built a custom Notes app for >> invoicing and billing and am wondering if there is a programmatic way to >> create transactions and records in gnuCash. If so, what languages/tools are >> needed to talk to the program? I am also curious how transactions are >> stored internally. XML? Ideally, I would like to create a connection that >> would allow either the Domino server, or a server agnostic webservice to >> write and retrieve information from mobile devices/web forms. >> > > For thease reason and others in the mailing list (one about to have an > applet), is realy important to allow simultaneous multiaccess to the > GnuCash data. Agreed. We really need a viable multi-user backend for GnuCash. > Allowing other apps to use a library to connect to the data for > consult or modify, without need to run ANY GUI is one of the best > solution. I think the use of a GDA based interface could be usefull, > any could create powerfull (near to the standard SQL instructions) > queries for insert, update or delete, using GdaQuery, connect to the > database backend using GdaDict. This library *must* ensure the data > integrity and, I think, works as a layer between the applications and > GC's data. I'll point out, YET AGAIN, that GDA is NOT necessary to solve this problem. One could just as easily write a new application against the existing GnuCash APIs and create their own application that doesn't use the standard GnuCash GUI. Having said that, GnuCash does not currently have a supported multi-user backend. That WOULD be a requirement, so I encourage you to help Phil Longstaff complete the GDA Backend in the gda-dev branch. -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
Hi, Please remember to CC the list on all your replies... "Samuel deHuszar Allen" <[EMAIL PROTECTED]> writes: > First, thanks for the quick response. A quick perusing through the Scheme > language docs makes me wonder. What's the best way to inject procedures? Is > learning Scheme a worthwhile endeavor? Or are there some quick bindings that I > can access using some common (non-C++ as I am a C-Dummy) XML exchange such as > SOA, SOAP, etc.? Can I use gnome GUI tools to invoke commands or scripts? I > want to be able to create a web-based interface, or some kind of transaction > broker that can inject/retrieve information from a local gnucash > installation. It looks like there's no gnucash server of any kind. You can get GnuCash to load new scheme procedures at runtime. It's not the EASIEST thing in the world, but it's possible. Note also that I said "C", not "C++". IMHO learning Scheme is always a good idea. It's a very useful language to know from a Computer Science point of view. It's very easy to learn (it should take a good programer no more than a day to really learn the syntax, and a week to learn the basic APIs). Adding SOA/SOAP etc. to gnucash would be MUCH more challenging. GnuCash (as-is) is a desktop applkication, not a web-app. No, there is no "gnucash server". > Without C++ knowledge, am I sunk? Thanks again for your help, and my > apologies for hand-holding requests. If I don't have to learn an enormous > high-level programming language to do what I want, I'd prefer to not. :) See above. There is no C++, there is only C. But if you don't know C and aren't willing to learn Scheme, then yes, you're SOL. > Thanks again. > > Sincerely, > Sam -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
Thanks for the feedback. I didn't know I was mailing to the gnucash list. I just clicked on the developer's mailto on the support site. I guess I've got some reading material ahead of me this weekend. :) Sam On 8/24/07, Derek Atkins <[EMAIL PROTECTED]> wrote: > > Hi, > > Please remember to CC the list on all your replies... > > "Samuel deHuszar Allen" <[EMAIL PROTECTED]> writes: > > > First, thanks for the quick response. A quick perusing through the > Scheme > > language docs makes me wonder. What's the best way to inject > procedures? Is > > learning Scheme a worthwhile endeavor? Or are there some quick bindings > that I > > can access using some common (non-C++ as I am a C-Dummy) XML exchange > such as > > SOA, SOAP, etc.? Can I use gnome GUI tools to invoke commands or > scripts? I > > want to be able to create a web-based interface, or some kind of > transaction > > broker that can inject/retrieve information from a local gnucash > > installation. It looks like there's no gnucash server of any kind. > > You can get GnuCash to load new scheme procedures at runtime. It's > not the EASIEST thing in the world, but it's possible. Note also > that I said "C", not "C++". > > IMHO learning Scheme is always a good idea. It's a very useful > language to know from a Computer Science point of view. It's very > easy to learn (it should take a good programer no more than a day to > really learn the syntax, and a week to learn the basic APIs). > > Adding SOA/SOAP etc. to gnucash would be MUCH more challenging. > GnuCash (as-is) is a desktop applkication, not a web-app. No, there > is no "gnucash server". > > > Without C++ knowledge, am I sunk? Thanks again for your help, and my > > apologies for hand-holding requests. If I don't have to learn an > enormous > > high-level programming language to do what I want, I'd prefer to > not. :) > > See above. There is no C++, there is only C. But if you don't > know C and aren't willing to learn Scheme, then yes, you're SOL. > > > Thanks again. > > > > Sincerely, > > Sam > > -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 >[EMAIL PROTECTED]PGP key available > -- Samuel deHuszar Allen If I don't have the right solution, you have the wrong problem. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
2007/8/24, Derek Atkins <[EMAIL PROTECTED]>: > Quoting Daniel Espinosa <[EMAIL PROTECTED]>: > > > 2007/8/24, Samuel deHuszar Allen <[EMAIL PROTECTED]>: > >> I am a Lotus Notes / web developer. Have built a custom Notes app for > >> invoicing and billing and am wondering if there is a programmatic way to > >> create transactions and records in gnuCash. If so, what languages/tools > >> are > >> needed to talk to the program? I am also curious how transactions are > >> stored internally. XML? Ideally, I would like to create a connection that > >> would allow either the Domino server, or a server agnostic webservice to > >> write and retrieve information from mobile devices/web forms. > >> > > > > For thease reason and others in the mailing list (one about to have an > > applet), is realy important to allow simultaneous multiaccess to the > > GnuCash data. > > Agreed. We really need a viable multi-user backend for GnuCash. > What do you think is the BETTER way to do so? > > Allowing other apps to use a library to connect to the data for > > consult or modify, without need to run ANY GUI is one of the best > > solution. I think the use of a GDA based interface could be usefull, > > any could create powerfull (near to the standard SQL instructions) > > queries for insert, update or delete, using GdaQuery, connect to the > > database backend using GdaDict. This library *must* ensure the data > > integrity and, I think, works as a layer between the applications and > > GC's data. > > I'll point out, YET AGAIN, that GDA is NOT necessary to solve this > problem. One could just as easily write a new application against > the existing GnuCash APIs and create their own application that > doesn't use the standard GnuCash GUI. > I realy considering to do that. I don't know way you think that but... > Having said that, GnuCash does not currently have a supported > multi-user backend. That WOULD be a requirement, so I encourage > you to help Phil Longstaff complete the GDA Backend in the gda-dev > branch. > You say: "multi-user backend", but it isn't the same that a "multi-user enviroment" , I think the solution is: a) Create a GnuCash Server a la Evolution, this allows any application to use the GC's data, but this enviroment just allow connections from the same computer and in a bussines software like GnuCash, you will need to get multiple connections from diferent computers (the accountant, the cashier, the owner, etc.) b) Allow GnuCash to connect to a database server, in this escenario each user will get a GUI frontend (actual GC's GUI) and will share data with others using the multi-user enviroment by the dabase server (this will be archived by the GDA backend), but it doesn't allow any other application to use the GC's data and make sure it is using it in the way GC does, keeping the data consistency and run the riquired actions actualy in the GC's engine. c) Allow multiple applications to connect to the GC's data by an API, the data must be stored in a database server to get a multi-user enviroment. With this any application can use the data in a consistent way and doing just GC's engines wants to. As an adition you can allow anyone to create the GUI according with its inviroment. QOF dataset query engine is very limited and we want GDA give QOF with the multiuser features GC needs, I think that GDA must replace QOF. GDA can give us the same functionalities: datasets and queries, but in a powerfull version, and the multi-user features required by GnuCash. I'm actualy working in a library to get the same functionalities in GC's engine but using directly GDA. This library must export an API to be used by any application to get access to the data. -- 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
Re: Questions about gnuCash backend access
"Daniel Espinosa" <[EMAIL PROTECTED]> writes: > 2007/8/24, Derek Atkins <[EMAIL PROTECTED]>: [snip] >> Agreed. We really need a viable multi-user backend for GnuCash. > > What do you think is the BETTER way to do so? A GDA Backend. >> Having said that, GnuCash does not currently have a supported >> multi-user backend. That WOULD be a requirement, so I encourage >> you to help Phil Longstaff complete the GDA Backend in the gda-dev >> branch. > > You say: "multi-user backend", but it isn't the same that a > "multi-user enviroment" , I think the solution is: I think it depends on your definition of "environment". To me, I imagine a "multi-user environment" would be something like a small business office where multiple people need access to the same data file. That's an "environment". It has nothing to do with the actual implementation or coding; it's all a question of how the system needs to be used. A "multi-user backend" is a specific implementation. It would be an upgrade of the old Postgres backend, migrating it from pure postgres to GDA. > a) Create a GnuCash Server a la Evolution, this allows any application > to use the GC's data, but this enviroment just allow connections from > the same computer and in a bussines software like GnuCash, you will > need to get multiple connections from diferent computers (the > accountant, the cashier, the owner, etc.) I don't think this is necessary, and I think it would be overkill for the vast majority of users. It would imply a fairly major architectural change to GnuCash and I don't think the gain would justify the cost at this time. > b) Allow GnuCash to connect to a database server, in this escenario > each user will get a GUI frontend (actual GC's GUI) and will share > data with others using the multi-user enviroment by the dabase server > (this will be archived by the GDA backend), but it doesn't allow any > other application to use the GC's data and make sure it is using it in > the way GC does, keeping the data consistency and run the riquired > actions actualy in the GC's engine. This is required, and this is exactly what the GDA backend would supply. This is why I'm pushing it so hard. > c) Allow multiple applications to connect to the GC's data by an API, > the data must be stored in a database server to get a multi-user > enviroment. With this any application can use the data in a consistent > way and doing just GC's engines wants to. As an adition you can allow > anyone to create the GUI according with its inviroment. We already have this now.. Someone could write an application and link against the gnucash engine APIs and then load and use gnucash datasets. We would tie into a database through a GDA backend, just like we currently tie into an XML file via the File Backend. There's no new coding necessary to get this working, it's all there right now. > QOF dataset query engine is very limited and we want GDA give QOF with > the multiuser features GC needs, I think that GDA must replace QOF. > GDA can give us the same functionalities: datasets and queries, but in > a powerfull version, and the multi-user features required by GnuCash. This is arguable. I've still never seen an application proposal that couldn't use the existing infrastructure. You keep asserting over and over that you can't do it with QOF, but neither you nor anyone else has shown a concrete proposal for a real application that you intend to write that requires more than what QOF provides. So, at this time I still don't see this as a short-term or medium-term goal. It still feels like a solution in need of a problem, and it looks like a lot of work just to migrate from one dependency to another, for very little gain in the user experience or change in the API. I think you'd be better off, in the short term, migrating more object APIs over to Gobject, or working on the GDA backend with Phil. -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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
2007/8/26, Derek Atkins <[EMAIL PROTECTED]>: > "Daniel Espinosa" <[EMAIL PROTECTED]> writes: > > > 2007/8/24, Derek Atkins <[EMAIL PROTECTED]>: > [snip] > >> Agreed. We really need a viable multi-user backend for GnuCash. > > > > What do you think is the BETTER way to do so? > > A GDA Backend. > > >> Having said that, GnuCash does not currently have a supported > >> multi-user backend. That WOULD be a requirement, so I encourage > >> you to help Phil Longstaff complete the GDA Backend in the gda-dev > >> branch. > > > > You say: "multi-user backend", but it isn't the same that a > > "multi-user enviroment" , I think the solution is: > > I think it depends on your definition of "environment". To me, > I imagine a "multi-user environment" would be something like a > small business office where multiple people need access to the > same data file. That's an "environment". It has nothing to do > with the actual implementation or coding; it's all a question of > how the system needs to be used. > > A "multi-user backend" is a specific implementation. It would be > an upgrade of the old Postgres backend, migrating it from pure > postgres to GDA. > > > a) Create a GnuCash Server a la Evolution, this allows any application > > to use the GC's data, but this enviroment just allow connections from > > the same computer and in a bussines software like GnuCash, you will > > need to get multiple connections from diferent computers (the > > accountant, the cashier, the owner, etc.) > > I don't think this is necessary, and I think it would be overkill > for the vast majority of users. It would imply a fairly major > architectural change to GnuCash and I don't think the gain would > justify the cost at this time. > > > b) Allow GnuCash to connect to a database server, in this escenario > > each user will get a GUI frontend (actual GC's GUI) and will share > > data with others using the multi-user enviroment by the dabase server > > (this will be archived by the GDA backend), but it doesn't allow any > > other application to use the GC's data and make sure it is using it in > > the way GC does, keeping the data consistency and run the riquired > > actions actualy in the GC's engine. > > This is required, and this is exactly what the GDA backend would > supply. This is why I'm pushing it so hard. > > > c) Allow multiple applications to connect to the GC's data by an API, > > the data must be stored in a database server to get a multi-user > > enviroment. With this any application can use the data in a consistent > > way and doing just GC's engines wants to. As an adition you can allow > > anyone to create the GUI according with its inviroment. > > We already have this now.. Someone could write an application and > link against the gnucash engine APIs and then load and use gnucash > datasets. We would tie into a database through a GDA backend, just > like we currently tie into an XML file via the File Backend. There's > no new coding necessary to get this working, it's all there right now. > BUGS! (please refer to bugzilla for details): a) #470753 - There isn't any gnucash.pc file anywhere to export the actual API. b) #470750 - The actual documentation talks about some non-existent functions for gnc_book c) #470755 - Add support for multi-user access d) #470760 - Actual API doesn't allow to use GC's data As you can see we need to fix them before to say "it's all there right now". > > QOF dataset query engine is very limited and we want GDA give QOF with > > the multiuser features GC needs, I think that GDA must replace QOF. > > GDA can give us the same functionalities: datasets and queries, but in > > a powerfull version, and the multi-user features required by GnuCash. > > This is arguable. I've still never seen an application proposal that > couldn't use the existing infrastructure. You keep asserting over and > over that you can't do it with QOF, but neither you nor anyone else > has shown a concrete proposal for a real application that you intend > to write that requires more than what QOF provides. > If an external application needs to access the GC's data must do it using engine's API not QOF, then I found the following: MORE BUGS! (please refer to bugzilla for details): e) #470767 – Actual engine API doesn't export any function or gives a way to get access to the QOF datasets and or create a QofQuery. f) #470780 - Improve SQL support in QofQuery Most of this bugs could be fixed using GdaDataModel and GdaQuery, and inmediately access to tables, fields, rows or any object like triggers in the database manipulation using GDA's GObjects. I realy want Gnumeric or even OpenOffice, to get access to GC's data and use their powerfull financial functions to get great financial analisys, more sofisticated graphs, tendencies and more. QOF or GnuCash doesn't allow give any method to share data with this applications. GDA has some integration level with Gnumeric. An applet will be usefull in order to help end
Re: Questions about gnuCash backend access
"Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> Well I still wait for my patch to be applied to QofCollection (see bug
> #453502) and wants to alling the current API convention to GObject's
> one (see bug #470788).
("alling" isn't an English word. What do you mean?)
Regardless, there's no *requirement* that we change the convention. They're
just that ... conventions. At the same time, most of us do want to change
the names and what not, but there are better and worse times to do it.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgp0nyZxxgn2r.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Questions about gnuCash backend access
2007/8/29, Josh Sled <[EMAIL PROTECTED]>:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> > Well I still wait for my patch to be applied to QofCollection (see bug
> > #453502) and wants to alling the current API convention to GObject's
> > one (see bug #470788).
>
> ("alling" isn't an English word. What do you mean?)
>
I mean, is it convenient? is it usefull to use conventions from GObject?
I think an exposed API must be as mininal as possible, but feature
rich, clean and not expose any "potencial dangerous" functions used
just in the core's internals.
I'm writing a test program to use the actual API, measure its
usability and file bugs if potencial.
QUESTION:
QOF headers has a lot of coments pointing potencial bugs or even
actual bugs Can I add this as bugs in bugzilla?
>
> Regardless, there's no *requirement* that we change the convention. They're
> just that ... conventions. At the same time, most of us do want to change
> the names and what not, but there are better and worse times to do it.
>
I'm the one who wants to change "a lot of internals" and "exposed
externals", and yes I think there's better time than other to make
changes, but the main developers must agree what and where (defining
the future of the core) and start aa quick as possible, becouse we
need to spent a lot of time.
--
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
Re: Questions about gnuCash backend access
"Daniel Espinosa" <[EMAIL PROTECTED]> writes: > QOF headers has a lot of coments pointing potencial bugs or even > actual bugs Can I add this as bugs in bugzilla? I'm not sure what the advantage would be to having them either in two places (the comment and bugzilla) or one place (bugzilla) which is separate from the code. If you want to submit a patch that addresses a bug, it might be good to create a bugzilla entry as a place to attach the patch ... but mailing it to gnucash-devel is probably just as good. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpRg6fI0oKZZ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
