Re: Questions
I dont think there is a public CVS repository for g-wrap. However, for Gnucash-CVS you need g-wrap 1.3.2, which you can find at: http://www.gnucash.org/pub/g-wrap/source/g-wrap-1.3.2.tar.gz -derek Nick Hudson [EMAIL PROTECTED] writes: Im wanting to build gnucash from cvs and ive been trying to find a cvs for g-wrap. So far I have been unable to locate one. Any idea on where I can get the development version of g-wrap so that I can compile gnucash from cvs? Thanks Nick Hudson ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel -- 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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about reports
-BEGIN PGP SIGNED MESSAGE- On Friday 22 February 2002 09:03, Martijn van Oosterhout wrote: 2. I want my report to do slightly different things depending on whether something is an income or expense account. I see gnc:account-get-type except that there are several kinds of expense accounts and several types of income accounts. I could list the various types and use member to identify them, but this would break if a new type was added. All the other existing account types in Gnucash besides income and expense actually are neither income nor expense accounts. The other account types are all some variant of an asset or liability (or equity) account. So by testing (member '(income expense)) you should be on the safe side. And anyway, new account types don't get added that often (IIRC none during the last 3 years), so you wouldn't need to worry too much about that. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPHabQ2XAi+BfhivFAQGXjgP/c1QfYaQwdi902yuyhY6Sen1mOTo+C53t 9UpKP3IpDBrmaO9k7mRohfG6+MXD5KlIGH5FH7y4e32kGYdhbUmdupM0u6clVAaQ w04wtWyKvyTZi2zp2MMn5sTIkVwvAheefKfxUeL2DRSw211wNXsySRGkbdk5nFNH 2XdHae/ERig= =dCsb -END PGP SIGNATURE- ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about reports
Christian Stimming [EMAIL PROTECTED] writes: And anyway, new account types don't get added that often (IIRC none during the last 3 years), so you wouldn't need to worry too much about that. Actually, this is false.. I added Accounts-Payable and Accounts-Receivable account-types in CVS. Christian -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about reports
On Fri, Feb 22, 2002 at 05:54:44PM -0500, Derek Atkins wrote: Christian Stimming [EMAIL PROTECTED] writes: And anyway, new account types don't get added that often (IIRC none during the last 3 years), so you wouldn't need to worry too much about that. Actually, this is false.. I added Accounts-Payable and Accounts-Receivable account-types in CVS. This is exactly the problem. Perhaps there should be a account-get-base-type which returns one of asset, liability, income, expense or equity. Or predicates (like account-is-asset?). Instead of each report trying to work it out for themselves. There already are account-is-stock?, account-has-shares? and account-is-inc-exp?. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ If the company that invents a cure for AIDS is expected to make their money back in 17 years, why can't we ask the same of the company that markets big-titted lip-syncing chicks and goddamn cartoon mice? ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Thanks. More responses inline... Dave Peticolas [EMAIL PROTECTED] writes: The rollback is supposed to undo any changes which have been made since TransBeginEdit and restore the transaction to its original state. Restoring the data is actually done by the engine, so I'm presuming that backends would implement this by releasing any locks, etc. that were created by trans_begin_edit. Presumably, single user backends have no need to implement this callback. Linas will know more about this, though. That's what I thought. Since all the edits are done in the engine cache, the backend really just needs to unlock the structure. Is there any reason that we don't have a rollback on an account edit, too? 3) The 'sync()' operation seems to be an extremely heavy operation, especially for a networked backend. The operation is probably going to change. It is invoked by both 'Save' and 'Save As' functionality. But backends which implement the 'fine-grained' backend calls (like the sql backend) don't need to do anything during a 'save'. So the call will probably be split into two calls for that reason. Fair enough... Although I'm not exactly sure how 'save-as' will work for a fine-grained backed. For those backends the current file would always be up-to-date with the engine cache, so you're right, save would do nothing, and save-as would just copy the data elsewhere. However 'save-as' would never leave the original file as it was before any edits were made. I thought of another issue.. There doesn't appear to be a way for the backend to notify the engine that and account or transaction was deleted out from under it. This is probably related to question #2 below. Unless I'm missing something, during a sync operation there is no way to tell the difference between a "new" object or an object that was deleted in the backend. Thanks, dave -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: Thanks. More responses inline... Dave Peticolas [EMAIL PROTECTED] writes: The rollback is supposed to undo any changes which have been made since TransBeginEdit and restore the transaction to its original state. Restoring the data is actually done by the engine, so I'm presuming that backends would implement this by releasing any locks, etc. that were created by trans_begin_edit. Presumably, single user backends have no need to implement this callback. Linas will know more about this, though. Rollback for transactions in the multi-user case is sort of broken. If the data in the database is newer than whats in the engine, then any proposed updates from the user must not only be rejected, but the newer data from the database must also be pulled in. This isn't done yet. One other little problem: 'rollback' is used in two, unrelated ways. 1) by the gui, to implement 'undo' 2) by the engine, (when the above paragraph gets fixed). Some work needs to be done to disambiguate the above. That's what I thought. Since all the edits are done in the engine cache, the backend really just needs to unlock the structure. Is there any reason that we don't have a rollback on an account edit, too? Not yet implemented; see above. 3) The 'sync()' operation seems to be an extremely heavy operation, especially for a networked backend. The operation is probably going to change. It is invoked by both 'Save' and 'Save As' functionality. But backends which implement the 'fine-grained' backend calls (like the sql backend) don't need to do anything during a 'save'. So the call will probably be split into two calls for that reason. Fair enough... Although I'm not exactly sure how 'save-as' will work for a fine-grained backed. As it currently works, its a mass-copy of all data out of the gnucash engine into the named storage location. If the indicated storage location doesn't exist, its created, and all of the engine data is copied into it. If the storage location (i.e. database) does exist, and contains data, then the engine contents are merged into it. From the engine point of view, the above is the easiest thing to do. However, in some cases, it may not be what the user is expecting. For example: in the (unfinished) multi-user mode, the engine does *not* contain a full copy of the database data; instead, it contains only a subset. A 'save as', if implemented as above, would save only that subset, instead of all of the data. If the user thought 'save as' means the same thing as 'copy', they would be sorely disappointed. I don't currently have an opinion on the 'best' way of dealing with this situation. I thought of another issue.. There doesn't appear to be a way for the backend to notify the engine that and account or transaction was deleted out from under it. Or merely changed, for that matter. At some point, we'll need to work with Dave to fiugre out how to use the event system so that a backend can notify the engine that some other user has modified data. This is probably related to question #2 below. Unless I'm missing something, during a sync operation there is no way to tell the difference between a "new" object or an object that was deleted in the backend. U, ahhh, ohh... deleted splits are accounted for since we can detect that the number of splits in a transaction has changed. But if the entire transaction was deleted by some other user, then the engine currently would conclude that what it has is something new, not something deleted. I see two ways of fixing this. 1) Keep a master list of all transactions. If a transaction is not in the list, it should be deleted. (since, in theory, there is nno way to create a new transaction wihout putting it on the list). 2) Keep an audit trail of modified deleted transactions; and check that. I admit, the multi user case, with data caching in the engine, is proving more complex harder to implement than I anticipated. Where I last left it, account balances were giving me heartaches. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Thanks for the reply. Comment inline... [EMAIL PROTECTED] writes: Rollback for transactions in the multi-user case is sort of broken. If the data in the database is newer than whats in the engine, then any proposed updates from the user must not only be rejected, but the newer data from the database must also be pulled in. This isn't done yet. One other little problem: 'rollback' is used in two, unrelated ways. 1) by the gui, to implement 'undo' 2) by the engine, (when the above paragraph gets fixed). Some work needs to be done to disambiguate the above. Ok, so the rollback method implementation needs to get a return value from the actual data store (RPC Server in my case) in case the txn changed. This implies the client must send not only the txn guid but also the version number, and the return may include a new transaction. Good thing to know :) That's what I thought. Since all the edits are done in the engine cache, the backend really just needs to unlock the structure. Is there any reason that we don't have a rollback on an account edit, too? Not yet implemented; see above. So there is plans to have an 'account rollback' method (to rollback edits to an Account*)? As it currently works, its a mass-copy of all data out of the gnucash engine into the named storage location. If the indicated storage location doesn't exist, its created, and all of the engine data is copied into it. If the storage location (i.e. database) does exist, and contains data, then the engine contents are merged into it. Hrm. Perhaps certain back-ends might not support a 'save-as', or do all backends need to do it? Indeed, I'm not even convinced that 'save-as' makes any sense in a database or server-based backend. So, perhaps we just shouldn't provide the option for those types of backend? From the engine point of view, the above is the easiest thing to do. However, in some cases, it may not be what the user is expecting. For example: in the (unfinished) multi-user mode, the engine does *not* contain a full copy of the database data; instead, it contains only a subset. A 'save as', if implemented as above, would save only that subset, instead of all of the data. If the user thought 'save as' means the same thing as 'copy', they would be sorely disappointed. I don't currently have an opinion on the 'best' way of dealing with this situation. Well, I guess it depends on what the user expects, doesn't it? Worse, what might happen depends on what the backend is. I think a 'copy file' might require specific calls to the backend, although how would you 'copy file' from one backend type to another? A large can of worms, I agree. I thought of another issue.. There doesn't appear to be a way for the backend to notify the engine that and account or transaction was deleted out from under it. Or merely changed, for that matter. At some point, we'll need to work with Dave to fiugre out how to use the event system so that a backend can notify the engine that some other user has modified data. Agreed. Shouldn't be too hard. I just need to know what functions to implement, and the client will just receive them from the server and signal an event to the GUI. This is probably related to question #2 below. Unless I'm missing something, during a sync operation there is no way to tell the difference between a "new" object or an object that was deleted in the backend. U, ahhh, ohh... deleted splits are accounted for since we can detect that the number of splits in a transaction has changed. But if the entire transaction was deleted by some other user, then the engine currently would conclude that what it has is something new, not something deleted. :) I see two ways of fixing this. 1) Keep a master list of all transactions. If a transaction is not in the list, it should be deleted. (since, in theory, there is nno way to create a new transaction wihout putting it on the list). 2) Keep an audit trail of modified deleted transactions; and check that. The latter is certainly a reasonable option, although both would work. In my case, I'm actually depending on the engine (and another backend) to perform the actual data storage behind the RPC server. I admit, the multi user case, with data caching in the engine, is proving more complex harder to implement than I anticipated. Where I last left it, account balances were giving me heartaches. I'm just working on 'single-user' but I'm still only dealing with cached transactions. I'm still coding my 'first attempt', so I don't even know how account balances are supposed to work, or what information I need and when I need it. --linas -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]
Re: Questions about the Backend Interface
[EMAIL PROTECTED] writes: Any prefered API? gnc_login(char * username, char * passwd) ? This isn't enough for e.g. kerberos authentication, but maybe enough for now? Good question. I don't have a good answer. Assuming this is the function that the backend calls to ask the user (wouldn't the backend need some gpointer for window data?), I think a better API might be: int gnc_login (char *username, gint32 user_size, char *passwd, gint32 pass_size, gpointer arg) This way the backend can tell the UI: a) how big the username and password buffers are, and b) provide a UI callback arg for windows. Obviously, this would require the UI to register the CB arg, perhaps as a part of the 'book_open()' or 'book_load()' backend methods? 2) There appears to be no way for the backend to trigger an event to the engine/GUI if something happens. For example, I'd like the backend (server) to signal to the engine (client) that some information changed, or perhaps even pushing the changed information. Terminology, as used in gnucash: -- backend: the part of the client that knows how to talk to servers. -- engine: the part of the client that provides a data cache and a uniform API to the GUI. To answer your question: in practice, the backend can 'push' new data into the engine, because it has access to all the pointers structures. Hrm. Then perhaps the best way to 'trigger' an event is to have the server push the new data to the backend, and the backend can then push it into the engine and notify the engine that the data has changed? In principle, there is not yet any set policy: is the engine in charge and telling the backend to do its bidding (including optionally handling events that the backend generated?) Or is the backend in charge, mangling engine data as it sees fit? There are a number of ways of looking at it. My view is that the engine (data cache) and backend are all one thing, and the UI is a second part of the Gnucash client. Therefore, neither the backend nor the engine are 'in charge'. Either can change data, and when it happens they inform the other half. Obviously this means that when the UI changes data, it calls into the backend, and when the backend changes the cache, it calls into the engine that calls up to the UI. Opinions? Many approaches. Many choices. I don't know what's the best way. I think there are many ways of doing this that are all reasonable. -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: Thanks for the reply. Comment inline... [EMAIL PROTECTED] writes: Rollback for transactions in the multi-user case is sort of broken. If the data in the database is newer than whats in the engine, then any proposed updates from the user must not only be rejected, but the newer data from the database must also be pulled in. This isn't done yet. One other little problem: 'rollback' is used in two, unrelated ways. 1) by the gui, to implement 'undo' 2) by the engine, (when the above paragraph gets fixed). Some work needs to be done to disambiguate the above. Ok, so the rollback method implementation needs to get a return value from the actual data store (RPC Server in my case) in case the txn changed. This implies the client must send not only the txn guid but also the version number, and the return may include a new transaction. Good thing to know :) I think I want to retract some of my comments. By default, when the gui calls xaccTransRollback(), it will merely restore the data that was previously cached in the engine. And should mostly be enough: its highly unlikely that some other user changed the very same transaction, so its a waste of bandwidth to have to double-check with the server. In the event that the server data *did* change, then the 'standard' way in which the server notifies changes should be sufficient, and special 'rollbck' handling isn't really needed ... So there is plans to have an 'account rollback' method (to rollback edits to an Account*)? Yes. Hrm. Perhaps certain back-ends might not support a 'save-as', or do all backends need to do it? Indeed, I'm not even convinced that 'save-as' makes any sense in a database or server-based backend. So, perhaps we just shouldn't provide the option for those types of backend? Well, there's two ways that its important to support: a) its the only way (currently) of copying data from a prexisting file to a database. Its how one would migrate into sql. b) off-line operation: Say a user builds up a cache of data, saves it to a file, edits it off-line (e.g. while sitting at the airport) and then comes back on-line. The user will then want to 'sync' i.e. copy thier modified data into the server. Scenario b) needs work. What we have is almost right, but both the GUI, and a crisping up of the semantics is needed. The latter is certainly a reasonable option, although both would work. In my case, I'm actually depending on the engine (and another backend) to perform the actual data storage behind the RPC server. Yep, that's what I would have recommended. account balances were giving me heartaches. even know how account balances are supposed to work, well, if the engine has *all* of the splits in an account, it totals them up to get the running balances. But if it has a subset of all splits, then ... let me leave it at tat . --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: [EMAIL PROTECTED] writes: I think I want to retract some of my comments. By default, when the gui calls xaccTransRollback(), it will merely restore the data that was previously cached in the engine. And should mostly be enough: its highly unlikely that some other user changed the very same transaction, so its a waste of bandwidth to have to double-check with the server. Ok, so the rollback method is just an 'unlock'. Ok. Only if the begin method was a lock. For the postgres backend, its all 'atomic': when the gui calls xaccTransBeginEdit, its a no-op. When it calls xaccTransCommitEdit(), it locks, writes data, unlocks. A deadlock can't happen, since a lock is never held outside the scope of the backend. (i.e. all locks are released before the backend returns to the engine/gui). --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
[EMAIL PROTECTED] writes: Hrm. Then perhaps the best way to 'trigger' an event is to have the server push the new data to the backend, and the backend can then push it into the engine and notify the engine that the data has changed? Yes. Although the last step can be skipped: the backend itself can trigger the event mechanism to tell the gui that something changed (using suspend_events and resume_events in gnc-event.c, I beleive). Ahh, wonderful. Then all I need to do is create an 'update' callback. I wonder if it's safe to perform callbacks on single items, or if I should allow lists of updates to be pushed from the server? --linas -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
It's been rumoured that Derek Atkins said: [EMAIL PROTECTED] writes: Hrm. Then perhaps the best way to 'trigger' an event is to have the server push the new data to the backend, and the backend can then push it into the engine and notify the engine that the data has changed? Yes. Although the last step can be skipped: the backend itself can trigger the event mechanism to tell the gui that something changed (using suspend_events and resume_events in gnc-event.c, I beleive). Ahh, wonderful. Then all I need to do is create an 'update' callback. I wonder if it's safe to perform callbacks on single items, or if I should allow lists of updates to be pushed from the server? You probably want to batch as much as possible, otherwise the gui will flash and blink every time it tries to refresh itself. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
writes: It's been rumoured that Derek Atkins said: 2) There appears to be no way for the backend to trigger an event to the engine/GUI if something happens. For example , I'd like the backend (server) to signal to the engine (client) that some information changed, or perhaps even pushing the changed information. Terminology, as used in gnucash: -- backend: the part of the client that knows how to talk to servers. -- engine: the part of the client that provides a data cache and a uniform API to the GUI. To answer your question: in practice, the backend can 'push' new data into the engine, because it has access to all the pointers structures. Hrm. Then perhaps the best way to 'trigger' an event is to have the server push the new data to the backend, and the backend can then push it into the engine and notify the engine that the data has changed? Yes. Although the last step can be skipped: the backend itself can trigger the event mechanism to tell the gui that something changed (using suspend_events and resume_events in gnc-event.c, I beleive). We must be careful here. Presumably the Backend is going to receive information that the engine needs to be updated by some out-of-band mechanism like a signal. Right now, the Backend must not mess with the engine outside of the normal flow of control. Everything outside the engine has been written under the assumption that the engine cannot change outside of the current thread of control. Relaxing that assumption would require a significant amount of work. I think it would be much easier if the Backend informed the engine that it needs to be synchronized with the external source, and then the GUI event loop would poll the engine and, if needed, tell it to synchronize with the external source. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
[EMAIL PROTECTED] writes: You probably want to batch as much as possible, otherwise the gui will flash and blink every time it tries to refresh itself. Well, I was only referring to when data changes in the data-store. But I suppose that data there could be updated en-masse (ala sync()) so I should probably support a batched event notification. --linas -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Derek Atkins writes: Dave Peticolas [EMAIL PROTECTED] writes: We must be careful here. Presumably the Backend is going to receive information that the engine needs to be updated by some out-of-band mechanism like a signal. Right now, the Backend must not mess with the engine outside of the normal flow of control. Everything outside the engine has been written under the assumption that the engine cannot change outside of the current thread of control. Relaxing that assumption would require a significant amount of work. I think it would be much easier if the Backend informed the engine that it needs to be synchronized with the external source, and then the GUI event loop would poll the engine and, if needed, tell it to synchronize with the external source. This works well for Transactions. I could just have the server send a list of all the 'changed' transactions. The backend can just save that transaction list and signal that there is update work to be done. Then it can request the updated list of transactions from the server. I suppose I could do the same thing with accounts. However I'm going to have to change how I think about it. In particular, I need to change how I cope with account parenting. Currently I'm only transfering complete AccountGroups.. If I'm going to transfer a single account at a time, I'm going to need a way to signal that the parent changed. Unfortunately an AccountGroup doesn't have a GUID, so I really need to grab account-parent-parent-guid to figure out who my parent is (and assume that I'm a top-level account is account-parent-parent is NULL). Yes, that is the case. As long as the change happens in the normal flow of control, the GUI should handle reparenting gracefully. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Dave Peticolas [EMAIL PROTECTED] writes: Yes, that is the case. As long as the change happens in the normal flow of control, the GUI should handle reparenting gracefully. Ok, then all we need it a flag that I can set (from another thread) that the engine/gui loop checks and calls back into the backend whenever it's set. I presume I can use 'gnc_book_get_group()' to get the top-level group in book? If so, then we just need something like: void gncSetEventFlag (void); and the Backend method can be something like: void (*process_event) (Backend *be); dave -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
Dave Peticolas [EMAIL PROTECTED] writes: How about we make the 'are there events pending' call a part of the backend api as well. So the engine/gui would just ask the backend if there are events and the backend would clear the flag when they are handled. That way, backends which need to implement mutexes can do so and the rest don't need to. That works. Something like: gboolean (*events_pending) (Backend *be); ?? :) dave -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 [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Questions about the Backend Interface
I'll answer as best I can. Linas is more familiar with the Backend code so he will be able to give more information. Derek Atkins writes: So, I've been working on implementing an RPC backend, but I've got a few questions: 0) There appears to be no way to allow the backend to callback to the client to request a username/password or some other authentication. I don't like the "hack" of putting the username and password into the URL. I think Linas is planning on adding that in for the sql code so the RPC backend should be able to use the same hook. The dialog has already been created, it just needs to be added to the Backend infrastructure. 1) What is the purpose of the trans_rollback_edit() method? I can't seem to find any information on it, and as far as I can tell nothing actually implements it. My only guess is that it's the opposite of "begin_edit" when there aren't any changes (so, it's basically a "commit" without making any changes to the transaction. Is this true? The rollback is supposed to undo any changes which have been made since TransBeginEdit and restore the transaction to its original state. Restoring the data is actually done by the engine, so I'm presuming that backends would implement this by releasing any locks, etc. that were created by trans_begin_edit. Presumably, single user backends have no need to implement this callback. Linas will know more about this, though. 2) There appears to be no way for the backend to trigger an event to the engine/GUI if something happens. For example, I'd like the backend (server) to signal to the engine (client) that some information changed, or perhaps even pushing the changed information. Again, this hasn't been added yet. As Linas is starting to work on multi-user support for the sql backend, now is the time to explain what functionality the RPC backend needs as well. 3) The 'sync()' operation seems to be an extremely heavy operation, especially for a networked backend. The operation is probably going to change. It is invoked by both 'Save' and 'Save As' functionality. But backends which implement the 'fine-grained' backend calls (like the sql backend) don't need to do anything during a 'save'. So the call will probably be split into two calls for that reason. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
