I'm not sure I see how using libxml2 wouldn't give you a consistent API for app development. libxml2 is a consistent API you'd use.
dan Dale Anderson wrote: > True, although alot could be said for alot of other abstraction type > libraries in other projects, libxml2 has been around a long time and > having previously read the history on the project an assload of time was > spent on optimising the parsing routine so if things haven't speed up > over the period of the project theres likely a reason, the other benefit > is having a consistent API from an app development perspective. > > Dale. > dan sinclair wrote: >> I'm assuming that they'd love some performance related patches. >> Writing something from scratch isn't a good response to a performance >> issue unless there is some fundamental reason you can't make it >> faster/better. >> >> dan >> >> >> Dale Anderson wrote: >>> Libxml2 doesn't exactly provide stellar parsing performance does it?, >>> which appears to me a majority of peoples complaints regarding XML use. >>> >>> Dale. >>> >>> >>> >>> dan sinclair wrote: >>>> Jose Gonzalez wrote: >>>> >>>>> Massimiliano wrote: >>>>> >>>>> > > > Might I suggest exporting the efreet xml parser and use it >>>>> > > > instead? Does anyone object? Using strstr to parse xml isn't >>>>> > > > very nice. >>>>> > > > >>>>> > > > Sebastian >>>>> > > >>>>> > > On my side i don't have any preference, i initially wrote my >>>>> > > parser 'cause i've to parse a very small subset of tags, and >>>>> > > i rewritten it to make it better/faster and to have support for >>>>> > > media namespace. But if you think that efreet's parser is better/ >>>>> > > faster, feel free to change. >>>>> > > >>>>> > > Thx >>>>> > > >>>>> > > Massimiliano >>>>> > >>>>> > Still waiting for replies? >>>>> > >>>>> >>>>> I can't say that I've followed what this is about.. but if >>>>> it's something like wether "e" should have a good xml parser/api >>>>> vs. everyone who needs something like that having to write their >>>>> own... then I'd say it may be time for "e" to stop 'poo-poo-ing' xml >>>>> (mostly an excuse to avoid dealing with it) and consider developing >>>>> some solid support for it - for those that may wish to NOT write >>>>> their own when they need to use xml. >>>>> Like it or not, xml is here and not going away any time soon, >>>>> its use is almost universal - especially across the web, but also >>>>> locally as well. >>>>> >>>>> PS. >>>>> Wasn't there "exml" supposedly to deal with this? Or is that >>>>> another lib that has serious flaws or limitations? >>>>> >>>>> >>>> Why write our own when libxml2 works quite well? Seems like needless >>>> NIH to me. >>>> >>>> dan >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> enlightenment-devel mailing list >>>> enlightenment-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>>> >>>> >>> >>> > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
