On Wed, 10 May 2000 19:08:36 CDT, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]> said:
> On Wed, 10 May 2000, Bill Gribble wrote:
> > You can't even put it on a CD that you sell for $5. And saying "you
> > have to go download mySQL to be able to use this product" is (IANAL)
> > equivalent to selling it with the product, if a lawyer wants to get on
> > your butt about it.
> >
> > > I again repeat. The capabilities of MySQL (and others) ARE ADEQUATE
> > > for a large portion of the userbase. Support for them should not be
> > > rejected simply because they don't meet the needs of everyone.
> >
> > There *are* free alternatives. Free in this case means that if we
> > make gnucash depend on it, we don't restrict people's abilities to use
> > and distribute gnucash.
>
> The distinction is in "requires" and "can use".
There are two approaches:
a) Change over wholesale to MySQL or PostgreSQL, with all the resultant
horrid administrative results, bloat, and licensing questions.
Not particularly attractive.
b) Create some sort of "middleware" level in between GnuCash and the
"data store," thus providing the option of using your choice of:
[ Text File | Something-like-DBM | SQL DBMS ].
This permits not having _all_ of the bloat forced on you, if the
gentle user doesn't choose to adopt the SQL DBMS option.
Unfortunately, it has several costs:
1. The need to _implement_ the middleware level that knows how to
simultaneously cope with multiple data stores. This has a cost in
terms of the design effort. It may prove difficult to guarantee
that what is efficient with the SQL version is also efficient
with DBM files, and vice-versa.
2. It adds an extra layer of bloat to the SQL version.
3. More code to debug.
And I just don't see any "win" to be gained. The use of an SQL DBMS
largely increases the complexity of the system. The notable factor
in GnuCash that limits scalability is not the data representation,
but rather the register. Hopefully it's reasonably efficient, these
days, but it still has a need to represent each line that is to be part
of the scrollable region as part of the register object.
Writing reports means having to consider multiple simultaneous languages,
for instance. SQL may be the language for pulling together the _data_,
but it is not a reporting language. You have to write SQL to pull
data, and then embed that in some other language, whether PHP, Perl,
or Guile, in order to generate the report. Then comes the question
of rendering the report. Choice of HTML, Postscript, or perhaps some
other language (XML?). It could easily mean having to integrate three
languages together.
Added bonus: That approach is only valid for those that use the SQL
DBMS as the engine, so that there needs to be a separate reporting
infrastructure to support those that aren't using SQL.
> I (also) ANAL, but believe that there is nothing which precludes you for
> including explicit instructions on how to download and install MySQL for use
> with gnucash (or any other product).
>
> Fundamentally, the tradeoff is between "self contained" and easy/efficiency
> of use.
>
> What I DON
> What I DON'T want to see is gnucash relying on ANY particular DB.
> Reisfs or jfs might be a better solution in some cases. After all, we are
> using simple files right now and THEY WORK for many users.
>
> As much as some people might like to think differently, you really NEED much
> more expensive solutions to get the value that some people are CLAIMING that
> they get from Linux/PostgreSQL.
>
> Don't EXCLUDE other less-than-perfect solutions based on this FUD.
Flip side: I think it a wise move to exclude as many suboptimal
solutions as possible.
Trying to be all things to all people [e.g. - compatible with all sorts of
DBMSes] is liable to be an expensive proposition, in terms of:
a) Performance,
b) Bloat,
c) Choices of functionality.
The problem is that SQL systems, hash tables, B-trees, and XML dumps
have _substantially_ different properties, in terms of:
- Ordering of sets
- The expense of connecting for a "query"
- Amounts of code involved
I would think it far wiser to embed something like DB-lib, getting
something with _nicely_ predictable performance properties, so that the
system can be unambiguously tuned.
A _serious_ downside to "middlewaring" is that if someone says,
"Performance sux," it's going to be problematic determining if this is:
a) A problem that their MySQL install is messed up;
b) Some inefficiency in the part of the middleware that is MySQL-specific,
c) Some inefficiency intrinsic to the middleware (on all DB platforms),
d) Some inefficiency in the GUI
e) Some inefficiency in the GnuCash Engine, or
f) Some interaction between some of these components.
If we Just Say GDBM, a), b), and interactions thereof _disappear_.
If someone really wants to do some form of integration with PostgreSQL,
it would most certainly be a slick idea to have some way whereby
data can be pushed/pulled between GnuCash and an SQL DBMS. But I'm
really not convinced that integrating in a DBMS is a good move.
--
Rules of the Evil Overlord #84. "I will not have captives of one sex
gnuarded by members of the opposite sex."
<http://www.eviloverlord.com/>
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
