[EMAIL PROTECTED] (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.
> so that one could write a routine that automatically loops over all of these
> and for every field in an SQL table, called the corresponding setter.
> In other words, a generic object fetcher.
>
> > Perhaps I should re-kindle the RPC Backend ;)
>
> 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.
You're right, you don't need megabytes of data to just delete one
split. However a real-time event is not megabytes of data.
> --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.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
