[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Next generation of KOrganizer / Call for help: (fwd)
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-05-05 10:26:07
[Download RAW message or body]

On Wed, 05 May 1999, Waldo Bastian wrote:
>Bavo De Ridder wrote:
>> >> Regular ODBC is not flexible enough. It is very difficult to write a small
>> >> minimal driver since ODBC implementations have to implement all the
>> >> functionality the spec requires.
>
>And then:
>
>> Well, I am not an ODBC expert... you're probably right. I was just pointing at
>> the modular approach of OLE DB.
>
>And:
>
>> Indeed. ODBC is here, works, and has been used, tested and accepted by the
>> majority in the industry. So whatever happens, unless something new and working
>> appears (implemented off course) I think ODBC is the way to go. At least you
>> can't go really wrong when using ODBC.
>
>Please don't make bold statements like "ODBC is not flexible enough" if
>you
>don't have any experience with it.
>

When I say "I am not an expert" I mean that I don't know of every single detail
of ODBC. I do however now what it is, how to use it, it's strengths,
weaknesses...

>> I myself am a computer science student (last weeks :-) ) and mostly work in
>> theoretical computer science (subtyping, F-bounded subtyping, higher order
>> subtyping) this makes me very vulnerable to good theories, I am not always
>> interested in implementations. If it looks good on paper it is good for me.
>
>KDE does not run on vaporware. Something is useless until is
>implemented. So
>having nice theories is fine, but it doesn't bring us anywhere if you
>don't 
>implement it. 
>

Let me say this: KDE 2 + CORBA (mico) + ODBC will pave the way for Microsoft.
Using MICO will make the KDE both slow and a memory hog. A full CORBA 2.0
implementations is overkill for any desktop. The reason why DCOM is not that
slow or a memoryhog is because it integrates at a very low-level with the OS.
This is something Unix can't do. I would vote for a very lightweight ORB.
Something usable in a PDA...

ODBC was nice for the past 4-8 years but currently everyone in the industry 
is looking for something new, something that will connect to non SQL databases 
in an elegant way. Something that unites several different database in one 
(virtual) database, something distributed, lightweight, ... this is everything
ODBC is not.

>I really hope that Peter et.al. get some ODBC stuff going, if it turns
>out that
>it is not flexible enough it is early enough to change to something
>else. You
>are of course free to come up with alternative solutions. I love to test
>out
>new code :-)
>

I know, the "write-code-now" philosophy of the KDE has brought it where it is
now: version 1.1.1 with a whole bunch of programs and libraries. 

However, this same philosophy has brought the following deficiencies (spelling?)
to the KDE:

1) Widgets both in the KDE libs and Qt, no single based source, the industry
doesn't like not having a single codebase for this kind of fundamental
components
2) non-qt widgets often don't use the same specifications or conventions as their qt nephews.
3) the "write-code-as-it-is-needed" gave us a bunch of conventions, often not
compatible. This is something one can clearly see in the following projects:
kab (database usage), kmail (no kde-wide uniform messaging api), ...

My answer for item 1: make Qt the only allowed stable codebase for widgets.
Whenever you need a widget that doesn't exist in the Qt codebase you make a
K*** version. This version should be considered a testcase (this is what
Microsoft does when delivering new components with IE). Whenever the component
is stable enough, it should be offered to Troll for inclusion in the next
version of Qt. Only then, when it is released in Qt, it should be considerd a
stable, mainstream widget. This will make both the KDE and Qt more attractive
to commercial vendors and companies interested in Linux. Don't forget: Corel,
Novell, ... are not interested in Linux because it is better but because they
don't like Microsoft. 

Especially the last part needs thinking. Every larger project needs a major
goal and a working framework. The KDE has still to devise a way of making
standards. Clearly (and luckily) they don't want to make to same mistake
Microsoft made, that is force standards. But, standards are needed, no matter
how they are born, they are needed. If everyone starts programming their own
ideas for the standards, not the best standard will win but the project with the
most programmers and the fastest turn-around for working code will. One should
at least first discuss the goals and concepts of the standard before one should
start several projects. A few days back, I read a remark on this list going
something like this: the base kde libraries are almost non-readable for
everyone but the original developers. This imho is a sign that standards are
even lacking in the base libraries. A quick look at the KDE kdoc generated pages
gives you the idea the libraries where made by accident when someone discovered
he had a lot of classes wich could make a library. This is not the impression
one gets when looking at the MFC documentation (I am not saying MFC is good
...).

As a computer scientist I would at expect some factory classes in the KDE base
libaries, however, almost none are available, ... almost no usage of patterns,
no frameworks for the most common application types,  ...


BDR

>Cheers,
>Waldo Bastian
>bastian@kde.org
>-- 
>KDE, Making The Future of Computing Available Today       
>http://www.kde.org

[prev in list] [next in list] [prev in thread] [next in thread]