On Sun, 2003-06-22 at 14:30, Derek Atkins wrote: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > On Sun, Jun 22, 2003 at 02:49:40PM -0400, Derek Atkins was heard to remark: > > > [EMAIL PROTECTED] (Linas Vepstas) writes: > > Well, but that's kind of how the pg backend works currently. In most > > cases the SQL 'NOTIFY gncSplit;' messages gets turned into a > > GNC_EVENT_DESTORY. And there's specialcase code for dealing with > > two GUI's editing the same split at the same time. So the events > > are already there, and I think you still need to have the specialcase > > code. > > Except it's not very real-time (the client has to emit a query > to notice the event), and it's not very portable (it requires > pg). >
The libpq library is documented to be thread-safe, so I could put the notify polling in a fork(), using select() or pselect(), and have it generate a signal when it receives a notification. Pretty simple to accomplish in theory, but would require some signal handling architecture. Doesn't take up any extra CPU cycles, either. > I'm still up in the air about whether ONC-RPC is the right solution to > this problem, vs. XML-RPC/SOAP or perhaps some other (home grown) > network protocol. I also admit that it does move the problem > somewhere else, moving the "serializing" problem into gnucashd. I'd > have to really sit down and think about it longer. > I think that it's best to use standard protocols where possible. It's more portable, the learning curve is shallower for new developers, and it's easier to maintain. > While I really want to see a standalone SQL engine embedded into the > client to replace XML, I don't know how much effort I want to extend > personally to work towards real multi-user support. If it just falls > out of Matthew's work, great. OTOH, if it would reduce the wait-time > by 6 months to go forward without multi-user, I'm all for going ahead > without it. The SQL back end should be inherently multi-user. There's a certain amount of checking that can theoretically be safely skipped in a single user environment, but that's skipping I plan on adding later. For the moment, it's a multi-user architecture. For me, this is mainly a difference at the very lowest levels. The upper layers shouldn't care what type of access is being used (other that storing it in the Backend object). -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
