I just commit some changes to the NSXML* classes which try to do more
compile time checking for available functions. The version numbers I use
there are based on this file: http://xmlsoft.org/symbols.xml
I think we need to agree on a minimal version of libxml2 that we want to
support. I would like to suggest 2.7.8, but we could also agree on 2.4.30.
As I explained in my reply to Riccardo, these checks may not be
sufficient, if the header files don't match the installed library. If
this turns out to be a real issue, we may need to add more configure
tests for specific libxml2 features.
When I did this change I was also right in the middle of an attempt to
add support for namespaces. The code still passes all current test cases
for me. (But not my local tests for namespaces :-()
This may not be that case on other systems, please report back whether I
introduced new issues with other versions of libxml2.
Namespaces turn out to be rather complicated to add to the NSXML
classes. There we are able to create attributes and elements with a
prefixed name even when there isn't a namespace definition for that
prefix. In that case we need to store a temporary namespace definition
somewhere and later replace it with the real one. I have a few ideas
here, but implementing them turns out to be rather complicated. And we
also need to support the case where we have the href but no prefix...
This also led me to rethink the memory management for namespace
NSXMLNodes. The same libxml2 node for a namespace could be used in
different places in an XML tree, we don't have a chance to take over the
memory management here, as we did with normal nodes that are only
allowed in one place in the tree. I think the best we can do here is
copy the namespace node each time we move between the libxml2 world and
our NSXML world. Otherwise we could end up referencing freed nodes or
leaking nodes. I haven't implemented that, but this bit seems simple and
the slow down for not caching the object for a namespace node should be
minimal.
Fred
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
