Design Decisions

[Linas Vepstas]

On Fri, Aug 29, 2003 at 04:17:53AM -0400, tripp+gnucash-devel at perspex.com was heard to remark:
> > Client-server is a statement about network technology, and not about
> > application design. Client-server is a set of design priniples that
> > allows multiple users to access a single database.
> 
> I don't mean to be contrary, but this is not strictly true. Client-server
> (at least these days) simply implies a separation between (well, this

Client-server involves, by definition, the network.  No product can 
rightfuly call itself client server unless the client can run on a
different host than the server.

> In that sense, then, as I understand the gnucash architecture, "engine"
> could stand on its own as a server of the six basic object types. The fact
> that it does so in-process at present is does not invalidate its
> server-ness, it simply changes the transport layer from sockets or pipes
> to the stack...

The gnucash client-server interface is called 'the backend'.  It is
placed there instead of at the front of the engine for performance
reasons:  one has a much, much more efficient network protocol at
the backend than you do at the fron of the engine, which is where
the programming API is.  The API has calls like "what is the value of
this siplit" which would be highly inefficnet over the net.

> Is it safe to say that an application trying to link transitionally to
> both Gnome1 and Gnome2 would have a "hard time of it" (which is to say,
> blow chunks all over the floor and be too sick to clean up its own
> godawful mess)?

Yes. You cannot have an elf executable link to both glib-1.4 and
glib-2.0 without crashing during startup.  And its 'worse' with gnome.

> If, instead, the GUI were a federation of components wagging their tails
> at each other to accomplish the end result, then (so the theory goes) any
> one of those components could be replaced without worrying too much about
> any bindings -within- each of the components.

There is no way to do what you are proposing within one address space,
due to the design of shared libraries and the way they are linked in
Unix.  (This is not a limitation on other OS'es).  

The only way you could 'fedrate' on unix is to use separate processes
and IPC's. pipes.   At this point the design becomes much much more
complicated, because you get race conditions and deadlocks.  Performance
can also suffer: a sburoutine call takes dozens of instructions, and IPC
takes hundreds of thousands.

> (and, yes, I'm aware of the relative cost of out-of-process calls vs.
> in-process calls; I've written an ORB and many distributed systems in my
> day. I maintain that Moore's law makes better architecture possible :) ).

OK. Unix still does not have an easy-to-use ORB.  I dunno, wait ten
years?

> What was that story about the railway line that refused to add a stop
> because they sent out a representative to the station and he didn't see
> anyone waiting for a train at that time? :-)

Well, this goes back to the other issue, 'what is effective
communication'?  There's a bit of chicken and egg. Or maybe
more like riverboat captian: you have to start the turn long, long
before the boat actually starts turning.

> Of those mechanisms, two are broken, and one (the SQL approach) is, to me,
> a less elegant way of approaching multi-user and client-server systems. As

Actually, if you use SQL, yu get the multi-user abilites 'almost for
free'. There is some extra complexity, but not much.  For me, less
complexity == more elegant.

> a developer, I'm going to take more time to "get around to" working with
> that code if I know I first have to get it into working condition.

?? You won't get around to working with feature X until I get feature X in
working condition ??  

> one care[s]" might actually be "no one has made their care apparent yet
> because the startup friction is too high to overcome whatever else they've
> got on their plate right now".

Well, that's the same difference.  Saying "I'm too busy to care" is
slightly more polite than saying "I don't care" but its the same net
effect.  I personally "care" about a great many things in the world,
but it would take 100 lifetimes to get around to them all.  

In principle, if somone builds it, someone else will come. . But 
we built two. Three, actually, and no one came.  Now, that may be 
because we didn't advertise enough. It may also be that what we built
wasn't what the people wanted. 


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933