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

2007-07-29 Thread Maciej Stachowiak


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


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-07-29 Thread Lars Knoll
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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev