XML size (was: no subject)

[Paul Lussier]

In a message dated: Wed, 03 Apr 2002 12:43:45 CST
Rob Browning said:

>Paul Lussier <plussier@mindspring.com> writes:
>
>> Are you planning on writing an ASCII Import feature as well?
>
>Absolutely -- if we went this route...

Okay, this was never stated anywhere, and someone seemed to be 
proposing an export feature as a way to placate those of us arguing 
for an ascii file.

I'm basically happy as long as there's a way for me to export my data 
to ascii after every session "just in case" and re-import it in case 
something "bad" happens.

(please don't use qif for the export/import format ;)

>One thing you may be underestimating is how much easier certain things
>would be code-wise if we switched to just using SQL (while still
>providing a text import/export process).
>
>There are all kinds of things you can say trivially in SQL (say with
>one line of text) that would require a lot of hand-written C or scheme
>to do if we weren't using SQL.
>
>So if we could make it so that using SQL across the board wasn't too
>bad for the average user (i.e. we make it mostly transparent).  It
>seems likely to me to have non-trivial benefits on gnucash's internal
>complexity and future features.

Please don't take this the wrong way.  As a user, I'm not concerned 
with what it takes to program something.  I certainly appreciate it 
from a programming perspective that there are trade-offs one can make 
to allow the programming to be easier.  But, as a user, I'm not 
concerned about it.

Let me be the user advocate here for a minute.  There are 2 ways to 
write an application.  One is writing it from the perspective of the 
programmer; i.e. write the code in the manner it's easiest to program.
The other is from the perspective of the user.  Write the code so 
that the end application is easiest to use.

My experience has shown me that programmers of applications are 
seldom the users of the same application.  The write the code and 
design the interfaces in the manner that's easiest to code.  When 
using the application themselves, they justify any quirks or awkward 
bits by recognizing that if they had done it any other way, it would 
have taken more time and more code.  Programming this way is almost 
always the wrong way to do things if your end goal is to enamour 
other non-programmers into using your application.

Developing the application from the perspective of the user's 
experience, regardless of how much extra code or effort is almost 
always the "right thing" to do, since this almost always *enhances* 
the user experience.

Now, if the application can be written in such a way to reduce code 
and complexity not only without detracting from the user experience, 
but also by *enhancing*, then go for it.  However, by it's nature, 
the user experience almost always requires extra code and complexity.

My personal feelings here are that the only real arguments for moving 
to an SQL back end are to enhance the programmer's experience, not 
the user's experience.  Performance increases will not be noticed by 
the large majority of users, and I don't really hear anyone 
complaining about performance issues to begin with.  Nor do I hear 
anyone complaining about ridiculously large "core" sizes, or anything 
else.  The only thing I hear people complaining about is the lack of 
certain features.

That tells me that time and effort spent on re-designing the data 
storage back-end are mis-directed, since the customers aren't 
complaining about anything affected by it.  Time and effort would 
therefore be better spent on enhancing the feature set.

Once that's done, debugged, tested, and shipped, if you want to go 
back and tweak things, great.  Just don't let it take away from the 
user's experience.

>I completely agree that having a text export/import format is
>important (and again, I'd propose that we always keep one, and even
>use it for regression tests so we know it still works), and you could
>probably do your editing there, but bear in mind that the SQL you have
>to know to be able to do some of the things you're talking about is
>*really* easy (off the top of my head, and probably a bit wrong):
>
>  update gnc_transactions
>    set description='foo' where description='bar';
>
>or similar (of course it wouldn't be quite this easy, but hopefully
>you get the idea).

Though I agree with you wrt the above statement, I ask, how many "average"
users do you know that know any SQL?  They understand "search/
replace" and they know how to fire up a text editor.  They don't know 
SQL.

I am not an average user, and I know enough SQL to get by.  However, 
I'd still rather use 'sed', 'perl', or emacs/vi than SQL.  It's just 
easier, and it's a lot faster, considering I'd have to search the web 
for an on-line SQL reference everytime I needed to do something 
trivial.

>> Additionally, I currently have my gnucash file under RCS.  Try 
>> putting an SQL database under RCS.
>
>Hmm, FWIW I can't recall if we're actually sorting the output.  If
>not, RCS might not be buying you that much (at least storage size
>wise) over just keeping compressed complete copies of the file.

RCS allows me to isolate "sessions" of changes to my data.
I can, at any point in time, check out the data file for a specific 
"revision" and get a snapshot picture of what my finances were like 
at that point.  Additionally, they allow me to log comments in 
association with any given session.  This is immensely useful for 
remembering what it was I was working on last, where I left off, and 
what I have left to do.  AND, it's directly tied to my data, so I 
don't have to worry about keeping a separate log file somewhere.

To me, it buys me a HUGE amount.  But that's me.  I don't care it 
there's not another person in the world who works the way I do, this 
works for me, and GnuCash, in it's current state, allows me to do 
this.  To change to SQL back end would not allow me to do what I'm 
currently doing, and would, really, not be any better for me than 
Quicken, other than it runs on Linux.

But, that's just me.  I really don't expect the architecture designs 
for GnuCash to be made only according to what I want, I'm just 
voicing my opinions in hopes that I'll be heard.  If, ultimately,
things go against my wishes, well, c'est la vie.  But I'd be derelict 
for not at least voicing how I feel :)
-- 

Seeya,
Paul