<div dir="ltr">Hello, sorry to bring this old topic up again. Nothing has happened in the last year or so, and this issue is bothering me again...<br><br>I am thinking that libxml2 should be somehow considered &quot;default&quot; since it is used by most existing ports, and also is quite portable, making it likely that new ports will use it. Maybe this idea will make it possible to make a patch that permits using something else than libxml2 without having to patch build systems other than qmake.<br>
<br>Would it be possible to use a variety on the ResourceHandle porting approach and have a WebCore/dom/XMLTokenizerBase.{h, cpp}. The libxml2 implementation lives in WebCore/dom/XMLTokenizer.{h, cpp}. If you don&#39;t specify in your build system that you should use WebCore/dom/port/XMLTokenizer.h and WebCore/dom/port/XMLTokenizerPort.cpp, you will get libxml2.<br>
<br>An added bonus is that you don&#39;t have to come up with a better name than &quot;XMLTokenizerLibXml2.cpp&quot; since it&#39;s still called &quot;XMLTokenizer.cpp&quot;.<br><br>/Arvid<br><br><div class="gmail_quote">
On Sun, Jul 29, 2007 at 7:53 PM, Lars Knoll <span dir="ltr">&lt;<a href="mailto:lars@trolltech.com">lars@trolltech.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sunday 29 July 2007 08:47:50 Maciej Stachowiak wrote:<br>
&gt; On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote:<br>
&gt; &gt; On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:<br>
&gt; &gt;&gt; On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Other organizations have requested the ability to use other XML<br>
&gt; &gt;&gt; parsers as well, such as expat. Seems like in the long run we want a<br>
&gt; &gt;&gt; different approach than just ifdefs in the XMLTokenizer.cpp file. It<br>
&gt; &gt;&gt; seems like the best would be some abstraction layer on top of the<br>
&gt; &gt;&gt; parser library, but if that is difficult then your option #2 sounds<br>
&gt; &gt;&gt; like a docent long-run approach. I would have expected just about<br>
&gt; &gt;&gt; every XML parsing library to have a SAX-like API, which shouldn&#39;t be<br>
&gt; &gt;&gt; too hard to abstract, but perhaps QXml works differently.<br>
&gt; &gt;<br>
&gt; &gt; I guess that assumption doesn&#39;t hold. QXmlStream is a streaming<br>
&gt; &gt; parser with an<br>
&gt; &gt; API that is very different from SAX. It IMO a whole lot simpler to<br>
&gt; &gt; use than a<br>
&gt; &gt; SAX like API and is inspired from similar APIs in the Java world. If<br>
&gt; &gt; you&#39;re<br>
&gt; &gt; interested, have a look at<br>
&gt; &gt; <a href="http://doc.trolltech.com/4.3/qxmlstreamreader.html" target="_blank">http://doc.trolltech.com/4.3/qxmlstreamreader.html</a><br>
&gt;<br>
&gt; I&#39;m told libxml has a StreamReader-style API now as well, so if that&#39;s<br>
&gt; the better alternative, we could design the XML code around that style<br>
&gt; of API (though probably not right at the moment).<br>
<br>
</div>No, for the moment, I&#39;d rather just go with the approach I&#39;ve posted in bug<br>
14791. Once there are requests for more parser backends, we could rethink<br>
this, but for now I think we have more urgent things to do.<br>
<br>
Cheers,<br>
<font color="#888888">Lars<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br></div>