On Fri, 13 Aug 1999 16:57:29 PDT, the world broke into rejoicing as
"Jesse D. Sightler" <[EMAIL PROTECTED]> said:
> Rob Browning wrote:
>
> > Also, bear in mind that most of the crashes I've seen were most likely
> > caused by the UI code (as you mention), and on the GNOME side at
> > least, we have been relying on a beta quality widget to implement the
> > register (GtkSheet).
>
> Huh? Doesn't gnumeric use GtkSheet? I could hardly describe something
> used so successfully in that project as "Beta" quality. :)
>
> I will say that I basically agree with you about CORBA right now,
> though. There's really too much complexity, with few real benefits for
> Gnucash right now. Your security concerns are almost certainly
> overblown :), but it's still not big improvement for Gnucash in any way
> right now.
A better idea, to my mind, would be to go with something Rather Simpler.
It *would* be a win to have the "engine" be a separate process from the
"GUI," as this permits the latter to crash without forcibly injuring
data. To that end, it might be an idea to *consider* looking at a
messaging system. There's a GNU Message Oriented Middleware package
that has apparently been deployed commercially for a while, but recently
GPLed. Look for Isect; <http://pweb.netcom.com/~tgagne/index.html>
I am completely undecided as to what CORBA implementation would be
preferable to consider; the "GNOME ORB" is, of course, ORBit. On the
other hand, ILU supports vastly more languages, and even permits support
of garbage collection, at the cost of that part of it not being CORBA
compliant...
I suspect that the *true* correct answer is to debug what we have now
until it works.
Another thing that might be helpful would be to create a "stress test"
for the engine, to see what makes it crash, and hopefully work from there
to finding out how to make it crash less.
The "I'm undecided" part is pretty important (whether you care what
[EMAIL PROTECTED] thinks or not); there are lots of possible decisions
that would result in having to rearchitect much of the system, thereby
putting off robustness further still, without actually having the result
of having something that works.
The only approach that I'd see as feasible for a "successor" would be to
have a project start by building an engine, making that work, and then
writing programs *THAT ARE SEPARATE PROCESSES* that talk to that engine.
That would help out considerably in the "don't crash" area...
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
