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

List:       kde-core-devel
Subject:    Re: Ksycoca backwards compatibility & freeze
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-04-03 21:08:41
[Download RAW message or body]

On Mon, Apr 03, 2000 at 01:33:04PM -0700, Waldo Bastian wrote:
> Hiya,
> 
> There will be a (small) problem by the time we get to KDE 3.0 (or any other
> version which is binary incompatible with 2.0) and before that when people
> upgrade KDE versions after 2.0 on a running system.
> 
> The problem arises when two different versions of KDE are running which require
> different versions of KSycoca. Currently the version of KSycoca on disk must
> match exactly in version with the one supported by kdelibs.
> 
> I would like to change this so that an older version of kdelibs can use a newer
> KSycoca version (on disk). For this to work some (small) changes are needed to 
> the way how KSycoca stores some information in the database.
> 
> The API will not be changed by this. 
> 
> Boring Details:
> The function allMimeTypes (and other "all" functions) read mimetypes
> sequentially from the database. This will break if newer versions of the
> database store more information per mimetype, the old kdelibs will then only
> read the old mimetype-info and assume that the extra mimetype info is the start
> of the next mimetype. To solve this problem we need to store a list with
> the starting position of each mimetype. Then newer version can store more
> information per miemtype which will just get ignored by the older version.

Sounds good.
Slows down a little bit the all* methods, but those aren't supposed to 
be used too often anyway (in theory only kcmfiletypes - but that's theory).

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2

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