sqlite file format, anyone?

[Derek Atkins]

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:
> > 
> > > OK, what I was thinking of was more along the lines of having something like:
> > > 
> > > static LoadObjectDef setters[] = {
> > >     { ACCOUNT_NAME_, LOAD_STRING, (Setter)xaccAccountSetName },
> > >     { ACCOUNT_DESCRIPTION_, LOAD_STRING, (Setter)xaccAccountSetDescription },
> > >     { ACCOUNT_NOTES_, LOAD_STRING, (Setter)xaccAccountSetNotes },
> > > };
> > 
> > Ahh, I see what you mean here.  I don't think I want the "load-string"
> > per se, but adding a "setter" to the object definition would be a
> > reasonable first step.
> 
> OK, Great. Yes, I glossed the details (like 'whats the sql table name',
> and etc.) but I'm pretty sure that this is what I really want to have
> at the lowest levels.

Remember that there are two things going on here.  The gncObject
interface is not all-encompassing, although if we had the setters as
well as getters then we could use it to create a dynamic UI for each
object.  A nice pipe-dream, but not one I care about right now.

> > > I'm not sure I understand. (I'm not sure I want to). Aren't you just 
> > > pushing the problem to a different place?  If one client deleted a 
> > > split, another client that's still holding the old split needs to be 
> > > able to figure out that it's copy is old, and, at some point, trash 
> > > it as well.  You shouldn't have to move megabytes of data across a 
> > > wire just to delete one split.
> > 
> > No, I'm not pushing the problem to a different place.  I'm trying to
> > make the problem easier to handle.  If we have a gnucashd sitting
> > between the client and the database then we can abstract the event
> > handling and get a real-time notification of deletions.  The client
> > can get the <GNC_EVENT_DESTROY, Split: GUID> event in real-time and
> > know that someone else destroyed the object.
> 
> 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).

> For me, comp sci often seems to be like a hall of transparent walls and
> mirrors.  Problems move around but never go away.
> 
> I should be careful, I suppose.  By having a gnucashd, the problem does
> mutate, maybe into something easier; I can't tell.  I'm not sure I want
> to think about it unless you are serious in pursuing that.

I am mostly serious about it.  I think that a "gnucashd" really does
make a LOT of things easier.  It would imply a single application
talking to the database so we don't need to worry about database
consistency as much.  It would mean we could implement real-time event
handling across multiple clients accessing the same database, even if
the database doesn't support event handling.

However, it would also be a major change to the infrastructure.  The
component manager would need to be added to the backend, and the RPC
code would need to be updated (and probably re-architected).  But I
also think that if we're going to continue with the "engine is a cache
and the database is just a storage mechanism" model that having a
gnucashd makes more sense.

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.

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.

> --lnas

-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
       warlord at MIT.EDU                        PGP key available