[webkit-dev] [webkit-changes] [24723] trunk/WebCore

[Arvid Nilsson]

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...

I am thinking that libxml2 should be somehow considered "default" 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.

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'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.

An added bonus is that you don't have to come up with a better name than
"XMLTokenizerLibXml2.cpp" since it's still called "XMLTokenizer.cpp".

/Arvid

On Sun, Jul 29, 2007 at 7:53 PM, Lars Knoll <lars at trolltech.com> wrote:

> On Sunday 29 July 2007 08:47:50 Maciej Stachowiak wrote:
> > On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote:
> > > On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:
> > >> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> > >>
> > >> Other organizations have requested the ability to use other XML
> > >> parsers as well, such as expat. Seems like in the long run we want a
> > >> different approach than just ifdefs in the XMLTokenizer.cpp file. It
> > >> seems like the best would be some abstraction layer on top of the
> > >> parser library, but if that is difficult then your option #2 sounds
> > >> like a docent long-run approach. I would have expected just about
> > >> every XML parsing library to have a SAX-like API, which shouldn't be
> > >> too hard to abstract, but perhaps QXml works differently.
> > >
> > > I guess that assumption doesn't hold. QXmlStream is a streaming
> > > parser with an
> > > API that is very different from SAX. It IMO a whole lot simpler to
> > > use than a
> > > SAX like API and is inspired from similar APIs in the Java world. If
> > > you're
> > > interested, have a look at
> > > http://doc.trolltech.com/4.3/qxmlstreamreader.html
> >
> > I'm told libxml has a StreamReader-style API now as well, so if that's
> > the better alternative, we could design the XML code around that style
> > of API (though probably not right at the moment).
>
> No, for the moment, I'd rather just go with the approach I've posted in bug
> 14791. Once there are requests for more parser backends, we could rethink
> this, but for now I think we have more urgent things to do.
>
> Cheers,
> Lars
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080910/0b2a13fa/attachment.html