Hello,
I am a student of computer science interested in entering Wine development via GSoC 2013.
Upon looking at the various suggested proposals, the project of reimplementing XPath without libxml2 looked particularly interesting. I am familiar with the C language, W3C DOM and XPath, and I believe this is something I could do.
I have a few questions I'd be interested in seeing answered: * One of the 'important things to keep in mind' is that "changes should be incremental, with a fallback to libxml2 until new processor is fully functional." Does this mean at compile time, or at runtime, when the evaluator recognizes unimplemented features in an expression, or something else entirely? * Is only MSXML 3.0 supported? It appears to be the only version implemented in the Wine source tree. * What should I aim at doing first? Because what I'd be working on is a library, I would probably need some application to test features with (test cases aside.) Should I be using an existing program, or writing a new one?
Thanks, John Chadwick
On 4/11/2013 05:52, John Chadwick wrote:
Hello,
I am a student of computer science interested in entering Wine development via GSoC 2013.
Upon looking at the various suggested proposals, the project of reimplementing XPath without libxml2 looked particularly interesting. I am familiar with the C language, W3C DOM and XPath, and I believe this is something I could do.
I have a few questions I'd be interested in seeing answered:
- One of the 'important things to keep in mind' is that "changes
should be incremental, with a fallback to libxml2 until new processor is fully functional." Does this mean at compile time, or at runtime, when the evaluator recognizes unimplemented features in an expression, or something else entirely?
Yes, what I meant is that a transition should be as smooth as possible, it should be a runtime check like you described - if processor doesn't support something that's needed to process given expression it shouldn't fail completely, but fallback to existing code.
- Is only MSXML 3.0 supported? It appears to be the only version
implemented in the Wine source tree.
It's just a way it's done. All code is in msxml3 dir, and msxml4 and msxml6 just forward to it, wine's msxml3 is able to create coclass versions that normally would live in msxml4 or msxml6. That's how code duplication is resolved.
- What should I aim at doing first? Because what I'd be working on is
a library, I would probably need some application to test features with (test cases aside.) Should I be using an existing program, or writing a new one?
You should be writing tests for XPath API, and it should be placed somewhere in msxml3/tests. Currently it lives in domdoc.c cause XPath is a part of DOM API, but it will be probably okay to create a separate file if amount of tests is expected to be large enough (and it is imho).
Speaking of tests, it should be easily extendible meaning that adding more tests should be mostly a matter of adding more test data and not that much of a code. Currently in existing XPath tests returned node set forms some string representation and we compare these strings with expected ones. I don't really like this way mostly cause it's hard to read and relate to original tree, but we could discuss that and make it better or find another way.
By the way, the main reason why I added this topic to GSoC page was that it seems to me that it's possible to implement it incrementally, this is a very important, and XPath implementation is a significant part of a long term plan to stop using libxml2 and have our own code (likely a lot of own code).
If anyone has anything to add here or is even opposed to such project for some reason, I'd really like to hear that.
Thanks, John Chadwick
On 11 April 2013 11:26, Nikolay Sivov bunglehead@gmail.com wrote:
By the way, the main reason why I added this topic to GSoC page was that it seems to me that it's possible to implement it incrementally, this is a very important, and XPath implementation is a significant part of a long term plan to stop using libxml2 and have our own code (likely a lot of own code).
What is the motivation behind moving away from libxml2?
Alex
-
Alex Bradbury -
John Chadwick -
Nikolay Sivov