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

List:       kde-pim
Subject:    Re: Need for a general purpose database in KDE (maybe kab)
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-07-12 1:05:18
[Download RAW message or body]


On 11-Jul-99 Mirko Sucker wrote:
>> Would you agree that it might be a plan to remove the STL stuff in there to
>> reduce the size (replacing with QTL) ? I had a quick go to see how easy it
>> would be and managed to get all the UI stuff to compile but got a little
>> sick
>> of trying to do the core code.
> 
> First it would not be leaner (at least not in future, since egcs will support
> template handling much better than before). I would say that changing from
> STL to QTL is wasted time - and it is not easy.

Ok. I had heard egcs' template handling would improve. I think --enable-final
gives us a similar effect anyway.

>> 2) There doesn't seem to be a way to change what kab understands at run
>> time.
>> For example, you can't add fields that kab doesn't know about.
> 
> You may add fields to the backend (the database interface) easily, but you
> need
> to define a binary interface to the apps that simply does only provide what
> the
> entry structures provide. For the rewritten kab library, new fields may (and
> will)
> be added.

What I'm looking for is that ability to handle _any_ field, simply by using
it. kab can know about a set of standard fields and a set of standard value
types. When it comes across a field name it doesn't recognise, its enum value
can be 'XField'. When it comes across a value type it doesn't recognise,
its enum can be 'XValue'. This still allows for you to add an extension field
with a standard value type. e.g. 'X-Anniversary' -> (ValueType)Date.

> Another point against it: If the interface needs QTL, all backends must have
> an
> interface to QTL and therefore link to Qt.
> Application developers will smack you about it.

Good point but it doesn't fix the Unicode problem.

> The STL string class has been dropped for kab II , since it is not supported
> everywhere.

Ok. What's the replacement ?

> Please see my message, as said above, and lets discuss on kde-pim.

I don't see another message.

> Definitly. But the problem is to unify our (Markus Wuebben and mine) and your
> plans.

Yes, but don't take me that seriously as I don't know what I'm talking about ;)

Is kabII in CVS or is it still a draft spec ?

Cheers,
Rik

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