API problems (Was: future versions)

[Bo Thorsen]

On Friday 06 February 2004 16:45, Oswald Buddenhagen wrote:
> On Fri, Feb 06, 2004 at 04:22:14PM +0100, Waldo Bastian wrote:
> > So then the question becomes which API parts are so bad that they
> > cause real hurt?
>
> /me whispers KProcess ...
>
> you'll be surprised how much pops up, if everybody revisits the (lib)
> stuff he worked with and remembers what weaknesses/annoyances he found
> in the past. maybe we should start collecting ideas in a central place,
> something like features.xml, but for the api. there is lots of stuff in
> the files themselves, but having everything in one place could be
> advantageous for finding correlations (i.e., weaknesses of whole
> concepts).
>
> and, fwiw, i don't buy the "maturity" statement that pops up now and
> then. some areas were not touched for years simply because nobody cared
> enough and felt up to the task. but that does not mean that the stuff
> is in a good shape. if you measure kde's api cleannes by qt standards,
> you'll find a picture not exactly to our favour, even with the current
> qt api, which matthias found to be sooo bad. ;)
> if changing that means annoying the poor application developers - too
> bad - for them.

FWIW, I don't buy the "revamp" argument. Unless it's done by a person that 
has made the initial implementation or has used the API for a long time, 
the revamper will just make other mistakes. That leaves everyone with 
changing APIs and less stability. Writing something isn't too hard. 
Making a substantial improvement usually is.

Another point for making fewer releases is to let libs stuff mature more 
outside kdelibs. One example of where this was not done is the resource 
framework. That should not have left kdepim for quite a while yet. 
Actually the only reason it did was that it was necessary to have it in 
libs to make the kabc resource work.

kdelibs is getting so good now, that it's actually possible to freeze the 
API completely for a longer time. Sure, there are lots of issues in 
there, but most of them really are only annoyances.

Bo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040206/cb6f32ad/attachment.sig>