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

[Maciej Stachowiak]

On Sep 10, 2008, at 4:08 AM, Arvid Nilsson wrote:

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

I think we should wrap the XML parser API at the platform/ layer. The  
main risk in doing so would be performance.

  - Maciej

>
>
> /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
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080910/39d5c588/attachment.html