Re: GDA: Status
Hi, Sorry for the delay, but I've been busy offline most of the weekend and yesterday so I've let this thread sit for a bit. More comments inline. Nathan Buchanan [EMAIL PROTECTED] writes: So...In the end, what's our options? 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be released in a bugfix release of GDA. The advantages of this approach are that we get access to sqlite, mysql, and postgres. The disadvantage is that we will probably have to ship our own version of GDA, and in a few years, this will probably be out of date, requiring the switch to V4 anyway. We will expend significant energy to have it working now, much of this energy will be lost when moving to V4. 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. We don't need to hope. Libdbi *IS* more stable and bug free. DBI has been out in the wild for AT LEAST half a decade, maybe more. It has providers for all the major OSS DBs as well as ODBC to connect to the non-OSS DBs. It is still being actively maintained but it's so rock solid that there just isn't much that NEEDS to be done. Another advantage is that DBI has been out in the wild and use-tested for a long time, so it's unlikely that we'd find any major gotchas along the way. It's benefits (and drawbacks) are well understood by the user community. The one major downside of DBI is that it IS lower-level than GDA. It does not really abstract out the query language like GDA does. It does provide a bunch of type abstractions, but doesn't provide a query abstraction. I also disagree with your statement of disadvantages. We would not have to re-do ALL the work done to integrade GDA. However we WOULD have do re-do a lot of it. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I'll restate my opinion here again. I think our #1 target is SQLite. We need to move our home users off of XML and into a DB so we can get the benefits of save-on-commit. Then MySQL and PG are tied (in my mind) for #2. Phil, do you have a preference? It's probably your preference that counts ;) I'm not going to push for DBI over GDA, however I do want to make sure we're making an educated choice here and not just choosing GDA because it's shiny and new and happens to have a 'G' in the name. I also want to make sure we're chosing a technology that WILL be there for a long time and wont get us stuck in a situation where we're spending all our time keeping up with them changing APIs out from under us. As an example, just look at what's happening in AqBanking. It's not a zero-effort task to move from AqB-2 to AqB-3. Luckily that work is limited only to a small section of Gnucash. Now imagine if we finish with GDA-4 and they move to GDA-5 (just like we almost finished with GDA-3 and now they're moving to GDA-4). Just let that simmer a bit. -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
Re: GDA: Status
Phil Longstaff [EMAIL PROTECTED] writes: Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? -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: Guile threading
Hi, Charles Day [EMAIL PROTECTED] writes: On Sat, May 31, 2008 at 11:07 AM, Derek Atkins [EMAIL PROTECTED] wrote: Keep in mind that most of the gnucash code is NOT thread safe! The whole reason I was thinking about threading was to be able to put progress bars directly in the QIF importer druid pages, rather than using popup dialogs (gnc_progress_dialog_xxx functions). I thought I could kick off a long-running Guile thread, then check its status occasionally and show the user how things are progressing. But threading doesn't seem to be an option. So maybe while Guile is running, it could just call a progress reporting function once in a while that updates the druid's widgets. Are there existing GnuCash functions that support progress bars and let me specify my own progress bar widget? (My guess would be no, since the splash screen would seem to be a similar case, and it appears to have needed to supply custom functions for updating its progress bar.) Um, I'm fairly sure we have guile wrappers for progress bar reporting functions. Indeed, I'm pretty sure the QIF importer already uses them for reading/parsing QIF files! Search for gnc-progress-dialog in qif-import/*.scm Cheers, Charles -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: gnucash 2.2.5 does not compile with libgoffice 0.6
Hi, Rainer Dorsch [EMAIL PROTECTED] writes: Hello, I am running Debian lenny and tried to compile gnucash. With libgoffice-0-6-dev installed I got: [snip] gnc-html-graph-gog.lo -MD -MP -MF .deps/gnc-html-graph-gog.Tpo -c gnc-html-graph-gog.c -fPIC -DPIC -o .libs/gnc-html-graph-gog.o gnc-html-graph-gog.c:47:56: error: goffice/graph/gog-renderer-gnome-print.h: No such file or directory gnc-html-graph-gog.c: In function ‘draw_print_cb’: gnc-html-graph-gog.c:671: warning: implicit declaration of function ‘gog_graph_print_to_gnome_print’ make[5]: *** [gnc-html-graph-gog.lo] Error 1 Doing the same with libgoffice 0.4 works flawless. What version of GtkHTML do you have installed? I seem to recall there being an issue that GtkHTML and GOffice needed to update at the same time, but configure doesn't do a good job of making sure the matches are there. Thanks, Rainer -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: Guile threading
On Tue, Jun 3, 2008 at 8:34 AM, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Charles Day [EMAIL PROTECTED] writes: On Sat, May 31, 2008 at 11:07 AM, Derek Atkins [EMAIL PROTECTED] wrote: Keep in mind that most of the gnucash code is NOT thread safe! The whole reason I was thinking about threading was to be able to put progress bars directly in the QIF importer druid pages, rather than using popup dialogs (gnc_progress_dialog_xxx functions). I thought I could kick off a long-running Guile thread, then check its status occasionally and show the user how things are progressing. But threading doesn't seem to be an option. So maybe while Guile is running, it could just call a progress reporting function once in a while that updates the druid's widgets. Are there existing GnuCash functions that support progress bars and let me specify my own progress bar widget? (My guess would be no, since the splash screen would seem to be a similar case, and it appears to have needed to supply custom functions for updating its progress bar.) Um, I'm fairly sure we have guile wrappers for progress bar reporting functions. Indeed, I'm pretty sure the QIF importer already uses them for reading/parsing QIF files! Search for gnc-progress-dialog in qif-import/*.scm Those functions are the same ones I mentioned above. They manage popup progress dialogs, whereas I am aiming to have a progress bar integrated into the druid page. Know of any functions that basically do the same thing as those, but let me specify existing widgets to use, rather than creating new ones? Cheers, Charles -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: GDA: Status
Derek Atkins wrote: Phil Longstaff [EMAIL PROTECTED] writes: Or would it be more expedient to pick a technology that has a proven track record, proven stability, is NOT a moving target, and is already available in most distributions? One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? I took a look at a few projects using libdbi. They seem to have some external mechanism (script) to create the db, and they also seem to have more of a permanent database idea (e.g. a reference database, a library contents database). Well, as long as queries and data modification stick to standard sql, gc could be ok. Note that there are some things which, whether standard sql or not, I would like to use if available e.g. the ability to insert multiple rows at a time (for slots) which is not supported by sqlite. We could abstract out the pieces. What I have written could be adapted. It's simply a question of risk. I'm not so tied to libgda that I couldn't switch, even now. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
One problem with libdbi is that its scope doesn't cover everything that libgda's does. From what I can tell, libdbi doesn't have any apis to cover table/index creation, and that is one area that has a lot of individuality (e.g. autoinc integer fields). Is that the only individuality? Or are there others as well? Could we abstract those pieces out ourselves? How do other projects using those technologies handle that? While not optimal, is it a practical issue? Most SQLite drivers automatically create database if the target doesn't exist (not sure about libdbi), and the tables could be created by a create new file user event. As for MySQL / Postgres, I can't imagine a user sophisticated enough to want this who would be unwilling to follow some simple directions to install the model. However, don't take this the wrong way, I'm not advocating we ditch gda - I'm leaving that decision up to Phil. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: Status
Derek Atkins wrote: 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? According to the libgda development mailing list, they are targetting 2.26 which seems to be scheduled for Q1 2009. Depending on distro release schedules, this means it may not be out in the wild until Q3 2009. I expect the gda-dev branch to be finished long before then. 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. We don't need to hope. Libdbi *IS* more stable and bug free. DBI has been out in the wild for AT LEAST half a decade, maybe more. It has providers for all the major OSS DBs as well as ODBC to connect to the non-OSS DBs. It is still being actively maintained but it's so rock solid that there just isn't much that NEEDS to be done. Another advantage is that DBI has been out in the wild and use-tested for a long time, so it's unlikely that we'd find any major gotchas along the way. It's benefits (and drawbacks) are well understood by the user community. The one major downside of DBI is that it IS lower-level than GDA. It does not really abstract out the query language like GDA does. It does provide a bunch of type abstractions, but doesn't provide a query abstraction. I also disagree with your statement of disadvantages. We would not have to re-do ALL the work done to integrade GDA. However we WOULD have do re-do a lot of it. From what I know now, we wouldn't need to redo *ALL* the work. However, it might be roughly equivalent to the amount of work to move from GDA-3 to GDA-4, which was a few weekends. A lot of the changes are simply based on the requirements of any SQL backend. My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I'll restate my opinion here again. I think our #1 target is SQLite. We need to move our home users off of XML and into a DB so we can get the benefits of save-on-commit. Then MySQL and PG are tied (in my mind) for #2. Phil, do you have a preference? It's probably your preference that counts ;) I'm not going to push for DBI over GDA, however I do want to make sure we're making an educated choice here and not just choosing GDA because it's shiny and new and happens to have a 'G' in the name. I also want to make sure we're chosing a technology that WILL be there for a long time and wont get us stuck in a situation where we're spending all our time keeping up with them changing APIs out from under us. My memory is that I chose GDA over DBI because DBI did not seem to be maintained. In fact, there is nothing on their page re release between Nov 2005 and Feb 2007 (I remember starting the project in 2006). What we are now finding is that GDA-3 will not be maintained (I don't have any current issues with it, but if I find one, who knows how it might get fixed in the field). So, with GDA, I think we have GDA-3 which has no maintenance (and may not be on all distros) and GDA-4 which won't be released for another 9 months. Moving to DBI would require: 1) a procedure to create a new db. As Albert Lash mentioned, perhaps support for building sqlite tables could be built-in and external procedures could be used to build mysql/postgres tables. I'm not sure how table upgrades because
Re: GDA: Status
Hi, On Tue, Jun 3, 2008 at 8:19 AM, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Sorry for the delay, but I've been busy offline most of the weekend and yesterday so I've let this thread sit for a bit. More comments inline. Nathan Buchanan [EMAIL PROTECTED] writes: So...In the end, what's our options? 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be released in a bugfix release of GDA. The advantages of this approach are that we get access to sqlite, mysql, and postgres. The disadvantage is that we will probably have to ship our own version of GDA, and in a few years, this will probably be out of date, requiring the switch to V4 anyway. We will expend significant energy to have it working now, much of this energy will be lost when moving to V4. 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost guaranteed that a release will happen. The advantages of this approach is that we will be current with the new GDA and releases will be done for us (or in conjunction with us - depending on how closely we work with the GDA team). Work done here will not be towards a dieing version. The disadvantages are that we will probably be limited to sqlite until the other providers are completed. We may have to distribute pre-release versions of the code until there is a 4.0 release, but after that, we hand it over to the official releases. The assumption here (in both #1 and #2) is that GDA-4 will be released sooner than that gda-dev branch will finish. I have seen no such assurance. What happens if gda-branch finishes, gets merged back into trunk, but GDA-4 hasn't been released yet? We'd be in the same predicament as we would be in with GDA v3 - needing to distribute our own code to make things work. I'm not saying this is ideal, just that it isn't any worse. It means that *we* cannot release GnuCash 2.4 because a major dependency (GDA) isn't available in the major distributions. This assumes we don't distribute any of it with our code. I believe we have done this sort of thing in the past, but it was before my time here. Also, in the past 18-24 months we've seen GDA move from 1.3 to 2.99 to 3.0 to 3.9/4! Are we really confident that in another 9-12 months they wont scrap this and move to GDA-5 and leave us in the dust yet again? A very valid point. 3. Use Libdbi/another approach. Advantages: we hope they are more stable and bug free, but do not know. Disadvantages: we have to re-do all the work done to integrate GDA :(. We don't need to hope. Libdbi *IS* more stable and bug free. DBI has been out in the wild for AT LEAST half a decade, maybe more. It has providers for all the major OSS DBs as well as ODBC to connect to the non-OSS DBs. It is still being actively maintained but it's so rock solid that there just isn't much that NEEDS to be done. Another advantage is that DBI has been out in the wild and use-tested for a long time, so it's unlikely that we'd find any major gotchas along the way. It's benefits (and drawbacks) are well understood by the user community. The one major downside of DBI is that it IS lower-level than GDA. It does not really abstract out the query language like GDA does. It does provide a bunch of type abstractions, but doesn't provide a query abstraction. This would be a significant shift in direction and it really would be up to Phill to make this change (as he's doing the work!). Honestly I'd have no objection to this, but the decision needs to come (IMHO) from the person doing the work. I also disagree with your statement of disadvantages. We would not have to re-do ALL the work done to integrade GDA. However we WOULD have do re-do a lot of it. Point taken, absolutes are hard to defend ;) Nathan My personal opinion is that we go with #2, use GDA V4. We will need to do fixes in either #1 or #2. From a maintenance point of view it's better to put those fixes towards a version that has a reasonable chance of a release. (This does, of course, assume that V4 actually gets completed). At best the other providers get implemented and we have all of them available. At worst, we're stuck with sqlite for a while. If we really need mysql/postgres right away - it's going to involve significant work regardless of the option chosen. I'll restate my opinion here again. I think our #1 target is SQLite. We need to move our home users off of XML and into a DB so we can get the benefits of save-on-commit. Then MySQL and PG are tied (in my mind) for #2. Phil, do you have a preference? It's probably your preference that counts ;) I'm not going to push for DBI over GDA, however I do want to make sure we're making an educated choice here and not just choosing GDA because it's shiny and new and happens to have a 'G' in the name. I also want to make sure we're chosing a technology that WILL be
