[Qt-interest] Qt-interest Digest, Vol 15, Issue 148

[Thiago Macieira]

Em Terça-feira 16. Fevereiro 2010, às 22.34.01, Ross Driedger escreveu:
> On 16-Feb-10, at 4:07 PM, qt-interest-request at trolltech.com wrote:
> > Which is a very good reason not to have it in Qt. DOM is a full API
> > and it
> > doesn't match Qt's principles or style.
> > 
> > Maybe we should remove the Qt convenience functions we added to QDom?
> 
> So is it part of the Qt philosophy to ignore established standards and
> invent something new that is incompatible with anything else?  Sounds
> more like Microsoft's way of doing things.

I thought that was the entire point. If the other standards were good enough, 
there wouldn't be a need for Qt. Qt exists because they aren't good enough and 
we are making something that is better than they are.

That goes for well-established standards like POSIX, STL, Win32, etc.

Another good example is also DOM: lots of people asked for DOM for WebKit 
after Qt 4.4. We stood our ground and didn't add the hundreds of classes that 
would be required for full DOM API. Instead, we made QWebElement, which still 
allows you to do what you want to do (access the object tree inside the HTML 
world) but without introducing an "alien" API.

> >> 2) There is a substantial code base that uses it.  I have invested a
> >> good deal of time converting my code from xerces to Qt and them
> >> extending it.  Can I invoice Nokia for the time and effort it will
> >> take to convert my code into some other proprietary XML model?  I
> >> didn't think so.
> > 
> > There was a great deal of code invested in Qt 3 before Qt 4 came.
> 
> Understanding that going from 3 to 4 represents an improvement.  Users
> have the choice of porting or staying, each with attendant
> disadvantages: a learning curve or not benefitting from
> improvements.   I can recall the yelps of protest over this and it is
> something that comes with the territory of making such a drastic
> change in versions.
> 
> Frankly, I do not see the advantage in ignoring a well established and
> independent standard.

See above.

And I will emphasise again that we are discussing Qt 5. QDom is not going 
anywhere in Qt 4.

> >> The more I think about this the angrier I get, considering that DOM
> >> support is one reason I chose Qt as my framework and that changing
> >> the
> >> implementation to suit something else will likely represent many
> >> month's work.
> >> 
> >> ...and I don't think Nokia will pay my invoice to convert my code...
> > 
> > What part of "Qt 5 is still many years away, it shouldn't be a
> > problem now"
> > was lost on you?
> 
> I don't know about you, but I intend my software to out-live Qt v4, v5
> and v6 (at the very least).
> 
> I'm not ready to chuck the framework for this, but be aware you have a
> commercial license holder who is not happy about this decision.

I really don't understand why. Why are you not happy about a decision we 
haven't made that may or may not influence you in 3 years (or more)?

The fact that QDom has seen less support right now in Qt 4 is both because 
there's little demand -- the classes are stable and they work -- and because 
we don't feel the value. Of course priorities will differ between us and you 
and between you and any arbitrary other reader of this mailing list.

So, yes, I will continue to recommend QXmlStreamReader because it's more 
efficient and I believe it's the future. You may disagree with me.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100216/e38ce206/attachment.bin