DB design document

[linas@linas.org]

It's been rumoured that Derek Atkins said:
> we're going to have to accept _some_ of the complexity in order to do
> what we want.
> 
> As for the clear requirements, you are correct -- we do need a clear
> set of requirements.  I've been trying to state what my requirements
> are, in terms of security, and I've been trying to glom usability
> requirements from other people.  But there isn't a requirements
> docuement anywhere that really describes where GnuCash is heading.

That's a good one.  Not for lack of trying.  Defacto, the only 
workable model seems to be (like any open source project), they who
itch and know how to scratch define what gets done.  I'd love to say
'it'll be this, or that', but no one particularly pays attention,
they just scratch the itches.



> > > investigate using ONC RPC as the marshalling system, which is much
> > > less overhead than CORBA, 
> > 
> > Its not obvious to me that any RPC has lower overhead than corba.
> > I'm tempted to beleive the opposite.
> 
> Then, unfortunately, you're tempted to be wrong.  RPC (I'm going to
> presume RPC == SunRPC == ONC RPC from now on) tries to bite off a much
> smaller problem space than CORBA does, so the required solution space
> is also much smaller.  

uhh, I am not an expert, but: what about the deamons rpciod, lockd, 
rpc.statd, portmap?  Last I understood, these had a variety of ways 
to be hijacked, via replay attacks, bogus udp packets, etc.  I also 
thought they introduced considerable latency: viz, having to look up a
service on one port number, (using udp, no less), and then another,
and then yet another lookup, just to find the service.   This was 
supposed to be fixed by WebNFS, but since WebNFS never happened ...  

Never mind that ssl-izing these deamons is not obviously 'easy'.

> Agreed.  The same is true for network functions.  It would be just as
> fatal to have the client-server pieces scattered throughout the
> system.

Again, don't let me stop you or discourage you.  I think this could
be a good, useful thing to do ... 

Here are a few more notes, to let you know where I'm coming from:
1) I'm pro-corba to the extent that it becomes a consistent
   part of gnome, and to the extent that gnucash really can provide 
   a good set of base fincial functions.  Corba has momentum.

2) I'm anti-corba for reasons described in
   http://www.vbxml.com/xml/articles/dotnetintro/default.asp
   Basically, its the fast-setting concrete issue: if the cleint
   and the server aren't exactly the same version number, they have
   trouble communicating. (same remark for rpc).  The beauty
   of xml-layered-on-http is that you have wiggle room that yo have
   explicit control over:  you can support different versions,
   different major & minor revision levels, without a lot of hassle
   or tears.  (viz. a whole lot less hassle & tears that corba)
   At least that's the theory.  Ask me again in 5-10 years.

--linas