DB design document

[Christopher Browne]

On 21 Dec 2000 14:19:40 EST, the world broke into rejoicing as
Derek Atkins <warlord@MIT.EDU>  said:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > Is it possible that the answer is to take the existing engine code and
> > separate the Query API into calls into a corresponding API on the
> > server side? I'm still getting familiar with the code, so I have only
> > a vague concept of its functions. But obviously the existing Query API
> > is working.
> 
> I think the Query API is only part of what we need.  Yes, we can use
> the Query API and have it "execute" on the server, indeed that was my
> plan.  However, we would still need the APIs to "write" changes to the
> data store (add/delete/modify splits/accounts/groups, etc.).

Yes, indeed.  The "CORBA way" would be to establish whatever set of
interfaces are useful for distributing the application.

Stuff like:
module GnuCash {
  interface Query {
    data structures, operations
  };
  interface Transactions {
    data structures, operations
  };
  interface Reconciliation {
    operations to reconcile transactions/accounts
  };
  interface Accounts {
    data structures, operations
  };
  interface LoginAuthentication {
    data structures, operations
  };
};

_Anything_ can get implemented or used badly or inefficiently; so
long as we try to use this sort of thing reasonably intelligently,
it doesn't _have_ to be slow.  

A typical "CORBA thing" might be for each account or even transaction
to be an "object" with affiliated IOR; if someone contended that this
fine-grained approach would have grand potential for grand inefficiency,
I would not disagree.  I wouldn't suggest that approach, but would 
rather suggest something a bit more coarse; each "user connection"
might be an object, which seems not unreasonable.

Even if the final conclusion is to not use CORBA, I would suggest that
organizing the set of "published functions" in IDL form may be very useful
in establishing what functions the GnuCash server should accept as calls.

By the way, supposing IDL proves to _not_ be the answer, I would
_strongly_ urge that there be some sort of automated scheme for
constructing the relevant interface code, ideally as an extension of
G-Wrap, so that it's not just all constructed haphazardly by hand.

Commenting on some other stuff...

>1. XML/SOAP (what Microsoft is calling "web services") to provide
>distributed RPC like services. This does much the same job as CORBA,
>but uses technologies that can be re-used elsewhere easily, and so have
>a low maintenance cost and a produce a lot of synergy (HTTP and XML).
>This can also take out a *lot* of the nastiness of cgi-bin, since you
>can just often just request information you want as if you were making
>a normal function call (well, ok, perhaps a bit more trouble).

_Unlike_ CORBA, XML/SOAP really only provides a generic messaging
system.  You're left with routing messages and interpreting them.
There's no equivalent to IDL; the nearest thing _maybe_ being an
XML DTD.

>2. XML/HTML with special embedded <objects> that rely on a particular
>"plugin" to provide rich functionality.  This is a bit like how Flash
>animations or things like that work.

You need to take a look at Bonobo; that is doing much of the same
thing.

>The neat new thing about 2 is that it is increasingly being used in an
>inside-out manner, with the web browser being embedded inside an
>application, and the application provides the semantics of the <object>
>tags.  

Herein enters the _next_ issue; this change requires embedding a
fullscale web browser inside the GnuCash client.  Anyone that has
protested the addition of minor additional dependancies should be
choking at this one!  Is the plan to embed Mozilla in GnuCash?  Or
Konqueror?  While "cool," this is a _MASSIVE_ addition.

>3. Server-side "dumbing-down" of 2 to provide an acceptable interface
>for dumb clients.  For example the GUI widgets in Microsoft's
>.NET WebForms libraries can be:
>(a) downloaded as bytecode to run on .NET runtime, user value changes
>are sent to the server using XML/SOAP callbacks
>(b) converted to a known set supported by IE 5.5, which turns them into
>neat graphical widgets using lots of JScript, sending results back using
>some sort of hackery I never really investigated
>(c) turned into standard HTML which Netscape can display, returning
>results with a standard form.
>Since 2 was just XML anyway, this is really just a transformation of XML
>-> XML or HTML.  Note that when you do this, you usually have to make a
>translation of any XML/SOAP calls you might want to make into cgi-bin
>calls.
>E.g. add links to the account names, which will generate a new page that
>gives a summary of that account.  In a rich client you might retrieve
>the summary yourself using SOAP/XML, and not even worry about loading
>the rest of the page.

As above, this mandates _completely_ reconstructing the front end of
GnuCash from scratch.  This is not GnuCash as we know it; it represents
its destruction and recreation from scratch.

It's certainly fun stuff to make up new architectures from scratch;
you're left with nothing functioning whilst making the transition,
and if you reexamine the architecture every year, it may never get
stable before it gets thrown away again.

By the way, SOAP/HTTP/XML is _not_ designed to be fast; it transfers
around XML _as text_, and has to parse XML continually.  IIOP is a real
"barn-burner fast" protocol compared to that...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
Blame it on the *-Property.