Re: GnuCash page on GO site

On Sun, Feb 22, 2004 at 11:26:56PM -0500, Jody Goldberg was heard to remark:
> On Sun, Feb 22, 2004 at 09:34:06PM -0600, Linas Vepstas wrote:
> > 
> > My apologies for the guppi fiasco. I feel responsible ... 
> > I trusted someone's word once that guppi was great shit even
> > thought my gut instinct went the other way.  And so I promoted
> > it to the gnumeric folks, making myself look foolish too ... 
> > again, my apologies.
> 
> Guppi was and is damn cool.  Trow had a huge pile of useful code in
> there.  Unfortunately, without him maintaining it there's just not
> much point in trying to move it along from the state it was in.
> He's just too damn smart.  Deciphering the design would have taken
> more work than just rewriting something simpler.

OK, then I retract what I said. I was remembering some arguements
with him over some trite design point, and then later getting swamped
by the code.  So I was unhappy about that.  It really needed to
be clasified, organized, documented, so that, as you say, mere
mortals could maintain it.

> Sure.  Merging best of breed toys into goffice would be a help.
> I suspect that overtime it may make sense to migrate towards some of
> the goffice data types to avoid having to map in and out, but that

I'm not sure what you refer to when you say "data types".  
If you mean using things like gconf, then yes, we should do that.
Our current way of dealing with user defaults & etc. is homebrew
and I see nothing wrong with moving to things like gconf type 
infraastructure. (right derek?)

But the actual financial data ... ugh.  We are disatisfied with 
the xml file format for a variety of reasons.  Its bloated, its slow,
it can't be extended or modified easily, Derek will happily tell you
everything wrong about it.  And then we have SQL... which is worse.   

On the other hand, having a nice infrastructure for allowing the 
to pick *which* data set they want to work with would be nice. 
So I've just been sort of waiting for the whiz-bang gnome-vfs 
file-picker widget, and that's all. 

But, to be honest, most of these things, like gnome-vfs and gconf,
are second-order concerns (at least to me, and I suspect Derek as well)
because we already have something that mostly works.  First order
concerns are that we are missing some core financial features
that users ask about almost daily on the mailing lists.   

> doesn't seem crucial.  The biggest step would probably be moving to
> libgsf, which I'd suggest.  The added transparency for i/o sources
> has been very nice.  It would be nice to see if it's support for
> files is strong enough for gnucash's needs (eg locking and
> transactions).

Well, the only file-locking that we do is to avoid classic data loss.

E.G. my wife on windows 3.1 for the first time.  Opened word processor.
Typed a bit, accidentally minimized the window and didn't know it.
Opened word processor again, and used same file name.  Worked for
hours, saved data. Shut down system, which asks "do you want to save
your data" to which she says yes.... unfortunately, that was the 
*first*, minimized instance that asked the question, and the "save"
of course over-wrote all her work.  This incident marks the begining 
of my hatred of Microsoft ... 

Another example: I lost gnucash data one day when I hit "save" but my
disks were full. It partly over-wrote the data file, garbled it. 
Ever since then, gnucash saves data by creating a *new* file, writing
to it, and then, only if the write is successful, will it rename the
new file to the old filename.   This might not sound hard, but it 
turned out that the flow chart for all the various error checks and 
popup dialogs to deal with those errors was actually surprisingly
complex.  It would be nice to have some gnome tool to handle the 
file save and walk the user through all the various dialog boxes,
but on the other hand, what we have works ... 

(yes, we've thought about auto-save. Its a touchy issue because of
data-loss concerns.)

--linas


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