Binary incompatibility issue in JuK saved data

Thiago Macieira thiago at kde.org
Tue Jan 8 12:01:41 GMT 2008


On Tuesday 08 January 2008 11:33:43 Will Stephenson wrote:
> On Tuesday 08 January 2008, Jaroslaw Staniek said:
> > Just a note, not necessary for JuK itself;
> > Isn't this a lesson for other projects saving to binary formats that it
> > would be safer to eventually migrate to a structured platform independent
> > storage like SQLite? (which is now the building block of KDE 4 anyway -
> > in strigi, akonadi, koffice, amarok, to name a few).
>
> QDataStream is version independent if you use setVersion.  I assume it's
> platform independent too, can someone who knows the truth here confirm
> that?

It is.

It's one of the reasons why the operators << and >> for long were dropped in 
Qt4 -- long itself isn't cross-platform. You have to explicitly cast to int 
or qlonglong.

There was a header in DCOP/Qt4 before it was removed that added the operator.

> Not to put down database storage, our database support is excellent, but
> for many uses it's using a hammer to crack a nut, and given the way people
> are taught computing these days, some will be tempted to go for what they
> know and use a database where a simple binary format is good enough and
> performs better than loading a database library and a db file and
> initialising the database and doing a query.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080108/72388dcd/attachment.sig>


More information about the kde-core-devel mailing list