sqlite file format, anyone?
Matthew Vanecek
mevanecek at yahoo.com
Sun Jun 22 22:14:55 CDT 2003
On Sun, 2003-06-22 at 14:30, Derek Atkins wrote:
> linas at linas.org (Linas Vepstas) writes:
>
> > On Sun, Jun 22, 2003 at 02:49:40PM -0400, Derek Atkins was heard to remark:
> > > linas at linas.org (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...
More information about the gnucash-devel
mailing list