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

List:       kde-devel
Subject:    Re: Why KAB isn't going to cut it.
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1998-12-22 21:05:50
[Download RAW message or body]

I haven't followed the Kab discussion from the beginning, but this what I
wanted to say:

Has anyone considered modeling Kab databases on top of LDAP? LDAP is the number
one emerging technology for those purposes. I am currently looking at ways of
using directory services and namespaces in the KDE environment. I already have
some very rudimentary blue-prints for a virtual namespace in the KDE. Instead
of accessing the regular filesystem directly, one would access it through an
extra virtual namespace layer. The virtual namespace would be constructed (at
runtime) from several existing namespaces like the filesystem, ftp-servers,
mail, static configuration data, ... The user would then browse that virtual
namespace without knowing it actually exists of several independent namespaces.

So a namespace would consist of directories and file-objects. File-objects can
be everything: regular files, versions of files, configuration data, LDAP
content, ... Every file-object has a corresponding (mime)type. A seperate
KDE Activation Framework would than be responsible for activating any necessary
program/library/KOM Part/... to perform the requested action on the file-object
with a particuar (mime)type. 

This is a project with a major impact on the existing KDE applications. At
least some parts of the KDE libraries will have to be rewritten: KFM, KFile,
....


Bavo De Ridder 





On Tue, 22 Dec 1998, Mirko Sucker wrote:
>I could not get my messages the last 2 weeks, so maybe I am a little bit late
>in this discussion.
>
>Preston Brown wrote:
>
>> > Can you tell us why it does not cut it?  I was looking forward to
>> > seeing a common address book...
>>
>> Sure.
>>
>> 1. I don't think that the addressbook library should force you to link in
>> kfm, kfile, kimgio, and all the other image libraries that go along with
>> it.  This SIMPLY ISN'T RIGHT.  If that isn't the intended result, we need
>> to change it.  Before 1.1. Or this thing is never going to see standard
>> use.
>
>This is the result of using widgets that use images, file IO, ...
>The vCard support that will be added after 1.1, for example, needs file IO,
>and the KDE way to do file IO is kfm or kfile, nothing else.
>Please consider that kab looks very trivial, but collects tons of different
>features
>in it, from calling other clients that use addresses to importing and
>displaying
>address information. This needs different libraries, and this is the
>intention of kab:
>to reduce the effort everybody has to put in address handling.
>That is why I wrote the Kab API.
>If you try to write your own one, you will (soon!) find that you need images,
>
>network and file IO. If you want to implement dropping of vCards from
>Netscape,
>for example, you will need libkfm.
>
>The only thing I can imagine to reduce this mass of libraries is to split
>kabs
>library into two part, the basic AddressBook class (that is even Qt
>independent (!)
>and very small) and the GUI elements. This would not be easier, but would
>allow
>to read kab addressbook databases without using any GUI elements.
>
>Another thing is that, when linking lots of libraries, this does not meen
>that the
>executable will use this big amount of memory. The libraries are loaded on
>demand
>on modern systems, and most of them are already in memory when running KDE.
>
>> 2. I don't mind STL, believe me I don't.  But:
>
>Compiling the STL is a matter that we should solve NOW. In future, it will be
>used
>in very basic parts of KDE (remember CORBA). It is now a PITA, but if we
>solve the
>compilation problems now, it is the most powerful container and algorithm
>library
>currently available. While Qt also provides good containers, it lacks the
>(more
>sophisticated) algorithms section of the STL. No offense...
>And, last but not least, complaining that the STL is hard to use now is
>useless, as it is
>part of the C++ standard.
>
>>   a. There are problems getting it to compile on some systems (not mine,
>>      thank God).
>
>On no system that uses gcc 2.7.x or egcs.
>On IRIX, the problems are solveable (I am working on it).
>gcc 2.8 produces problems, but this is a (another...) gcc 2.8 bug. Nobody
>recommends
>using gcc 2.8.
>
>>   b. We already have the Qt collection classes.  They may be slower and
>>      more antiquated/limited in certain ways, but ALL KDE APPS ARE USING
>>      THEM! This makes data interchange ALWAYS NECESSARY when you want to
>>      go from what you are using (a QString for instance) and a STL string.
>>      What a pain in the ass!
>
>This leads to the real problem.
>The problem is not the STL. It is the string class.
>You can use (or get a working copy of it) the STL with every compiler that
>supports templates.
>But most vendors do not package the string class with their compilers. That
>is (and the unicode
>thing) why I am considering to replace the usage of string-objects with
>QStrings. I will
>investigate this after KDE 1.1. It it not the right time for this now.
>And it is a different problem than the STL case.
>
>> I understand and fully value the time and effort that Mirko has put into
>> Kab.  However, it just doesn't seem (to me) to "fit" into the KDE
>> libraries like most of the other classes do.  It doesn't have a KDE "feel"
>> to it at all.  People are free to disagree with me.
>>
>> I'm afraid, I'm going to have to write my own address class (yes, yet
>> another one).  It will be built from the ground up to support vCards,
>> which at this point are rather standard and go hand in hand with
>> korganizer's support of vCalendars.
>
>As I said, kab will use vCards (not as IO basic, but as supported format)
>after KDE 1.1.
>
>Greetings,
>
>--Mirko.
>
>--
>Die Boerse ist ein armseliger Ersatz fuer den heiligen Gral.
>        (J.A. Schumpeter)

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