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
Questions about the Backend Interface
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. 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? 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. 3) The 'sync()' operation seems to be an extremely heavy operation, especially for a networked backend. Thanks, -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: guile-1.3.4
You will have to rebuild Gnucash and g-wrap, but it should work just fine. -derek David Bobroff <[EMAIL PROTECTED]> writes: > I want to upgrade to guile-1.3.4 for reasons having nothing to do with > Gnucash. It will require that I update some other things (umb-scheme, for > example) as well. Will this break any Gnucash dependencies? I'm currently > using Gnucash 1.4.10 and I have a recent CVS update of the development branch. > > Thanks, > > David Bobroff > > ___ > 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
guile-1.3.4
I want to upgrade to guile-1.3.4 for reasons having nothing to do with Gnucash. It will require that I update some other things (umb-scheme, for example) as well. Will this break any Gnucash dependencies? I'm currently using Gnucash 1.4.10 and I have a recent CVS update of the development branch. Thanks, David Bobroff ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Use of complete GList functionality? Change to GSList?
That's nice for the scheme side, but doesn't help when coding in C. :) At least in many cases it's easy to determine (either from member names or a quick code inspection) the data type of a list. Unfortunately this isn't true everywhere in the code. :( -derek [EMAIL PROTECTED] (Bill Gribble) writes: > On Sun, Mar 04, 2001 at 08:58:07PM -0500, Derek Atkins wrote: > > One of my major issues with the GList construct is that there is no > > way to validate the _type_ of list you've got. In other words, there > > is no way to be assured that you have list of type foo. I could pass > > a GList of type foo to a function that is expecting a GList of type > > bar, and there is no way to detect that. :( > > Well, RLB has addressed this problem with g-wrap by making it a > design-time problem. You can specify in the g-wrap def file that a > GList has a certain type of pointer in ->data... in fact, you are required > to do so... and it's a design "contract" on the C side that you must > build glists with that type. > > It's not compile-time type checking, or even run-time type checking, > which would be required for it really to be a contract, but there is > at least a handshake agreement that functions that return GLists > return GLists pointing to a certain type of data, and that that type > is documented in the g-wrap interface def file if nowhere else. > > b.g. > > ___ > 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: Use of complete GList functionality? Change to GSList?
On Sun, Mar 04, 2001 at 08:58:07PM -0500, Derek Atkins wrote: > One of my major issues with the GList construct is that there is no > way to validate the _type_ of list you've got. In other words, there > is no way to be assured that you have list of type foo. I could pass > a GList of type foo to a function that is expecting a GList of type > bar, and there is no way to detect that. :( Well, RLB has addressed this problem with g-wrap by making it a design-time problem. You can specify in the g-wrap def file that a GList has a certain type of pointer in ->data... in fact, you are required to do so... and it's a design "contract" on the C side that you must build glists with that type. It's not compile-time type checking, or even run-time type checking, which would be required for it really to be a contract, but there is at least a handshake agreement that functions that return GLists return GLists pointing to a certain type of data, and that that type is documented in the g-wrap interface def file if nowhere else. b.g. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
