QDataStream format change in Qt3.1

[Lubos Lunak]

On Thursday 12 September 2002 14:44, Matthias Ettrich wrote:
> On Thursday 12 September 2002 14:01, Lubos Lunak wrote:
> [snip]
>
> >  (*) Actually the only change between versions 4 and 5 seems to be
> > QImage, so for practical purposes it probably can be considered
> > compatible, but still, the problem of future versions remains.
>
> The change only effects QImage (meaning also QPixmap).  We should marshall
> (read: should have marshalled) a datastream version, but that's too late
> now.
>
> The problem isn't as serious as it looks, because most the marshalling
> functions are inside Qt. If you run a KDE 3.0.3 application linked to Qt
> 3.1, those apps will use the newer format as well => no problem.

 Even if we ignore that somebody might link statically for some weird reason 
(which we can ignore I guess), there still may be two apps in the same 
session using different libs. For example running KDE2 app in KDE3 
environment, or app started on different computer with forwarded DCOP (the 
single app on different computer case right now isn't probably that good 
argument, because it wouldn't have kded running on its computer, so I don't 
think it would actually work).
 When we one day have KDE4 and Qt4 and format of something in QDataStream 
changes, it may not work. I haven't tried running KDE2 apps under KDE3, but 
at least theoretically it should work, ksycoca format is supposed to be 
backwards compatible and the same about DCOP.

> Note that the DCOP protocol only is about sending a blob of bytes marked
> with a name to a certain object. It's KDE's protocol on top of those that
> interprets the name as a function name with parameters and the blob of
> bytes as the arguments written with a qdatastream.
>
> I do not foresee any futher format changes for the types we are using,
> meaning the problem is minor. The trouble with QImage was that libpng
> doesn't handle null images very well and we needed a way to stream a null
> image without error messages and unpredictable behaviour.

 When I says things like that, there's usually somebody to upset me by saying 
'famous last words' (it upsets me because they're often right).
 I can foresee two problems right now, and I even didn't have to think for 
that long.
 For example you might decide that it would be good if Q_INT32 would be 
actually 32bits even on 64bit platforms, which it's not as I can see in 
qglobal.h . Since for DCOP we use directly 'int', 'long' etc. and not these 
Q_INT32, this looks like a thing that might break it (and thinking about it, 
it looks like another reason why DCOP forwarded to another computer isn't 
that good idea).
 Or for Qt4 you might decide that 16bits for Unicode is not enough anymore and 
start using 32bits, just like wchar_t.
 Both these changes would break both DCOP and ksycoca. Can you really 
guarantee you will not make any such changes?


 If you really think this is not a problem, ok. If it is, IMHO we should 
rather solve this sooner than later, even though I'm not right now sure how.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/