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

List:       koffice
Subject:    Re: kword DTD (was "Koffice file format version numbers?")
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-05-25 11:29:55
[Download RAW message or body]

On Thu, May 25, 2000 at 02:15:15PM +0100, Shaheed Haque wrote:
> Hi Kalle,
> 
> >What would happen if you try to read a file with a newer version number
> >than your KWord binary? Or should the version number not be encoded
> >anywhere in the KWord code itself?
> 
> Good question - I'm not yet sure what the API allows. Certainly a kdError() 
> and possibly a message box popup...I'll know by the weekeend! If the current 
> API is not "perfect", then I presume that post 2.0, we'd extend it to deal 
> with this case.
> 
> BTW, I realise that if we could guarantee that all changes were upwards 
> compatible, we might be able to carry on in some failsafe mode, but that 
> will depend on things I cannot predict (and do not want to control!). For 
> example, let us imagine that the FORMAT section was enhanced in a newer 
> version of Kword - an older binary might simply be able to skip 
> tags/attributes it does not recognise.

Exactly. That's the strength of XML (compared to binary formats).
And that's the reason why I'm personnally not sure we need version
numbers at all. I mean, having some doesn't hurt, sure, but I don't see
any use for them in the code. If we even completely redesign the way something
is modelled, then we simply use new tags and keep the support for reading
the old ones (just like KoStore can still read old binary stores but not
write them anymore). And if we just add tags or attributes, old code
simply skips them.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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