Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
What version of libxml2 does this rely on?
-Sterling
chreguSun Feb 22 12:51:02 2004 EDT
Modified files:
/php-src/ext/xml compat.c expat_compat.h
Log:
Fix broken Namespace support, use libxml2 namespace methods instead of
homebrown solution:
- default namespaces are recognized
- different namespaces with same prefix in different nodes are treated correctly
- libxml2 parser warnings are not errors anymore
http://cvs.php.net/diff.php/php-src/ext/xml/compat.c?r1=1.25r2=1.26ty=u
Index: php-src/ext/xml/compat.c
diff -u php-src/ext/xml/compat.c:1.25 php-src/ext/xml/compat.c:1.26
--- php-src/ext/xml/compat.c:1.25 Thu Jan 8 03:17:45 2004
+++ php-src/ext/xml/compat.c Sun Feb 22 12:51:01 2004
@@ -33,119 +33,17 @@
((__ns) != NULL strlen(__ns) == 5 *(__ns) == 'x' *((__ns)+1) == 'm'
\
*((__ns)+2) == 'l' *((__ns)+3) == 'n' *((__ns)+4) == 's')
-static void
-_find_namespace_decl(XML_Parser parser, const xmlChar *tagname, const xmlChar
**attr)
-{
- xmlChar **attr_p = (xmlChar **) attr;
- xmlChar *name;
- xmlChar *value;
- xmlChar *partial;
- xmlChar *namespace;
- php_xml_ns *cur_ns_scope = NULL;
- php_xml_ns *exist_ns_scope;
- xmlNsPtr nsptr, curnsptr;
-
- exist_ns_scope = xmlHashLookup(parser-_reverse_ns_map, tagname);
-
- if (exist_ns_scope) {
- while (exist_ns_scope-next != NULL)
- exist_ns_scope = exist_ns_scope-next;
- }
-
- while (attr_p *attr_p) {
- name = attr_p[0];
- value = xmlStrdup(attr_p[1]);
-
- partial = xmlSplitQName(parser-parser, name, namespace);
-
- if (IS_NS_DECL(namespace)) {
-
- if (parser-h_start_ns) {
- parser-h_start_ns(parser-user, partial, (const
XML_Char *) value);
- }
- if (xmlHashLookup(parser-_ns_map, partial) == NULL) {
- xmlHashAddEntry(parser-_ns_map, partial, value);
- } else {
- xmlFree(value);
- }
-
- nsptr = (xmlNsPtr) xmlMalloc(sizeof(xmlNs));
-
- if (nsptr) {
- memset(nsptr, 0, sizeof(xmlNs));
- nsptr-type = XML_LOCAL_NAMESPACE;
-
- if (value != NULL)
- nsptr-href = xmlStrdup(value);
- if (partial != NULL)
- nsptr-prefix = xmlStrdup(partial);
-
- if (cur_ns_scope == NULL) {
- cur_ns_scope = emalloc(sizeof(php_xml_ns));
- cur_ns_scope-next = NULL;
- cur_ns_scope-prev = NULL;
- cur_ns_scope-nsptr = nsptr;
- cur_ns_scope-ref_count = 0;
-
- if (exist_ns_scope) {
- exist_ns_scope-next = cur_ns_scope;
- cur_ns_scope-prev = exist_ns_scope;
- } else {
-
xmlHashAddEntry(parser-_reverse_ns_map, tagname, cur_ns_scope);
- }
-
- exist_ns_scope = cur_ns_scope;
- } else {
- curnsptr = cur_ns_scope-nsptr;
- while (curnsptr-next != NULL) {
- curnsptr = curnsptr-next;
- }
- curnsptr-next = nsptr;
- }
- }
-
- } else {
- xmlFree(value);
- }
-
- xmlFree(partial);
- if (namespace != NULL) {
- xmlFree(namespace);
- }
-
- attr_p += 2;
- }
-
- if (exist_ns_scope) {
- exist_ns_scope-ref_count++;
- }
-}
-
static void
-_qualify_namespace(XML_Parser parser, const xmlChar *name, xmlChar **qualified)
+_qualify_namespace(XML_Parser parser, const xmlChar *name, const xmlChar *URI,
xmlChar **qualified)
{
- xmlChar *partial;
- xmlChar *namespace;
-
- partial = xmlSplitQName(parser-parser, name, namespace);
- if (namespace) {
- xmlChar *nsvalue;
-
- nsvalue = xmlHashLookup(parser-_ns_map, namespace);
- if (nsvalue) {
+ if (URI) {
/* Use libxml functions otherwise its memory deallocation is
screwed up */
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
Hi
mmmh, forget about that... I used 2.6.2, will test on 2.5.10 later
chregu
On 2/22/04 6:55 PM, Sterling Hughes wrote:
What version of libxml2 does this rely on?
-Sterling
chregu Sun Feb 22 12:51:02 2004 EDT
Modified files:
/php-src/ext/xml compat.c expat_compat.h
Log:
Fix broken Namespace support, use libxml2 namespace methods instead of
homebrown solution:
- default namespaces are recognized
- different namespaces with same prefix in different nodes are treated correctly
- libxml2 parser warnings are not errors anymore
http://cvs.php.net/diff.php/php-src/ext/xml/compat.c?r1=1.25r2=1.26ty=u
Index: php-src/ext/xml/compat.c
diff -u php-src/ext/xml/compat.c:1.25 php-src/ext/xml/compat.c:1.26
--- php-src/ext/xml/compat.c:1.25 Thu Jan 8 03:17:45 2004
+++ php-src/ext/xml/compat.c Sun Feb 22 12:51:01 2004
@@ -33,119 +33,17 @@
((__ns) != NULL strlen(__ns) == 5 *(__ns) == 'x' *((__ns)+1) == 'm' \
*((__ns)+2) == 'l' *((__ns)+3) == 'n' *((__ns)+4) == 's')
-static void
-_find_namespace_decl(XML_Parser parser, const xmlChar *tagname, const xmlChar **attr)
-{
- xmlChar **attr_p = (xmlChar **) attr;
- xmlChar *name;
- xmlChar *value;
- xmlChar *partial;
- xmlChar *namespace;
- php_xml_ns *cur_ns_scope = NULL;
- php_xml_ns *exist_ns_scope;
- xmlNsPtr nsptr, curnsptr;
-
- exist_ns_scope = xmlHashLookup(parser-_reverse_ns_map, tagname);
-
- if (exist_ns_scope) {
- while (exist_ns_scope-next != NULL)
- exist_ns_scope = exist_ns_scope-next;
- }
-
- while (attr_p *attr_p) {
- name = attr_p[0];
- value = xmlStrdup(attr_p[1]);
-
- partial = xmlSplitQName(parser-parser, name, namespace);
-
- if (IS_NS_DECL(namespace)) {
-
- if (parser-h_start_ns) {
-parser-h_start_ns(parser-user, partial, (const XML_Char *) value);
- }
- if (xmlHashLookup(parser-_ns_map, partial) == NULL) {
-xmlHashAddEntry(parser-_ns_map, partial, value);
- } else {
-xmlFree(value);
- }
-
- nsptr = (xmlNsPtr) xmlMalloc(sizeof(xmlNs));
-
- if (nsptr) {
-memset(nsptr, 0, sizeof(xmlNs));
-nsptr-type = XML_LOCAL_NAMESPACE;
-
-if (value != NULL)
- nsptr-href = xmlStrdup(value);
-if (partial != NULL)
- nsptr-prefix = xmlStrdup(partial);
-
-if (cur_ns_scope == NULL) {
- cur_ns_scope = emalloc(sizeof(php_xml_ns));
- cur_ns_scope-next = NULL;
- cur_ns_scope-prev = NULL;
- cur_ns_scope-nsptr = nsptr;
- cur_ns_scope-ref_count = 0;
-
- if (exist_ns_scope) {
- exist_ns_scope-next = cur_ns_scope;
- cur_ns_scope-prev = exist_ns_scope;
- } else {
- xmlHashAddEntry(parser-_reverse_ns_map, tagname, cur_ns_scope);
- }
-
- exist_ns_scope = cur_ns_scope;
-} else {
- curnsptr = cur_ns_scope-nsptr;
- while (curnsptr-next != NULL) {
- curnsptr = curnsptr-next;
- }
- curnsptr-next = nsptr;
-}
- }
-
- } else {
- xmlFree(value);
- }
-
- xmlFree(partial);
- if (namespace != NULL) {
- xmlFree(namespace);
- }
-
- attr_p += 2;
- }
-
- if (exist_ns_scope) {
- exist_ns_scope-ref_count++;
- }
-}
-
static void
-_qualify_namespace(XML_Parser parser, const xmlChar *name, xmlChar **qualified)
+_qualify_namespace(XML_Parser parser, const xmlChar *name, const xmlChar *URI, xmlChar **qualified)
{
- xmlChar *partial;
- xmlChar *namespace;
-
- partial = xmlSplitQName(parser-parser, name, namespace);
- if (namespace) {
- xmlChar *nsvalue;
-
- nsvalue = xmlHashLookup(parser-_ns_map, namespace);
- if (nsvalue) {
+ if (URI) {
/* Use libxml functions otherwise its memory deallocation is screwed up */
- *qualified = xmlStrdup(nsvalue);
+ *qualified = xmlStrdup(URI);
*qualified = xmlStrncat(*qualified, parser-_ns_seperator, 1);
- *qualified = xmlStrncat(*qualified, partial, strlen(partial));
- } else {
- *qualified = xmlStrdup(name);
- }
- xmlFree(namespace);
+ *qualified = xmlStrncat(*qualified, name, strlen(name));
} else {
*qualified = xmlStrdup(name);
}
-
- xmlFree(partial);
}
static void
@@ -157,14 +55,24 @@
if (parser-h_start_element == NULL) {
return;
}
-
- if (parser-use_namespace) {
- _find_namespace_decl(parser, name, attributes);
- _qualify_namespace(parser, name, qualified_name);
- } else {
- qualified_name = xmlStrdup(name);
- }
+ qualified_name = xmlStrdup(name);
+
+ parser-h_start_element(parser-user, (const XML_Char *) qualified_name,
(const XML_Char **) attributes);
+
+ xmlFree(qualified_name);
+}
+
+static void
+_start_element_handler_ns(void *user, const xmlChar *name, const xmlChar *prefix,
const xmlChar *URI, int nb_namespaces, const xmlChar ** namespaces, int nb_attributes,
int nb_defaulted, const xmlChar ** attributes)
+{
+ XML_Parser parser = (XML_Parser) user;
+ xmlChar*qualified_name = NULL;
+
+ if (parser-h_start_element == NULL) {
+ return;
+ }
+ _qualify_namespace(parser,
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
On Sun, 22 Feb 2004, Christian Stocker wrote:
mmmh, forget about that... I used 2.6.2, will test on 2.5.10 later
I think SAX2 support began with 2.6.0, but maybe you can enable SAX 1
usage for older version?
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
PHPAPI XML_Parser
@@ -415,8 +314,7 @@
parser-parser-replaceEntities = 1;
if (sep != NULL) {
parser-use_namespace = 1;
- parser-_ns_map = xmlHashCreate(10);
- parser-_reverse_ns_map = xmlHashCreate(10);
+ parser-parser-sax2 = 1;
parser-_ns_seperator = xmlStrdup(sep);
}
return parser;
@@ -498,7 +396,15 @@
PHPAPI int
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
This change requires libxml 2.6 in order to work (and compile). Rob On Sunday 22 February 2004 01:05 pm, Christian Stocker wrote: Hi mmmh, forget about that... I used 2.6.2, will test on 2.5.10 later chregu On 2/22/04 6:55 PM, Sterling Hughes wrote: What version of libxml2 does this rely on? -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 chregu On 2/22/04 7:34 PM, Rob Richards wrote: This change requires libxml 2.6 in order to work (and compile). Rob On Sunday 22 February 2004 01:05 pm, Christian Stocker wrote: Hi mmmh, forget about that... I used 2.6.2, will test on 2.5.10 later chregu On 2/22/04 6:55 PM, Sterling Hughes wrote: What version of libxml2 does this rely on? -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 In the meantime either add #ifdef configure checks or revert it out. Recognizing default namespaces shouldn't be hard to hack in to the code that was there, it just requires a bit of a rethink, and I believe we're set on supporting libxml2.5, right? -Sterling chregu On 2/22/04 7:34 PM, Rob Richards wrote: This change requires libxml 2.6 in order to work (and compile). Rob On Sunday 22 February 2004 01:05 pm, Christian Stocker wrote: Hi mmmh, forget about that... I used 2.6.2, will test on 2.5.10 later chregu On 2/22/04 6:55 PM, Sterling Hughes wrote: What version of libxml2 does this rely on? -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
On Sunday 22 February 2004 01:36 pm, Sterling Hughes wrote: Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 In the meantime either add #ifdef configure checks or revert it out. Recognizing default namespaces shouldn't be hard to hack in to the code that was there, it just requires a bit of a rethink, and I believe we're set on supporting libxml2.5, right? I personally would like to keep support for libxml 2.5, just because we know it works correctly and stable with the xml extensions and I for one have had little time to extensively test the xml extensions against 2.6.x. Other than that, I have no other reasons for supporting 2.5 However, I believe the namespace support for SAX wasn't introduced or at least wasn't fixed up until 2.6 so the issue may not be able to be fixed without requiring 2.6 That being said, if everyone really wants to require 2.6 I would be fine with it, but we may possibly be introducing new problems and will not be able to fall back to 2.5. From what I have heard from people running 2.6.x have reported, there have been no problems so far, but not sure how heavily they tested everything. Rob -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
Ok there are 5 different solutions now to this problem 1) fix the code, so that it works with 2.5.x correctly as well 2) make 2.6.x a prerequisite 3) disable xml_parser_create_ns for 2.5.x 4) use broken code for 2.5.x and fixed code for 2.6.x 5) revert to yesterdays situation (broken for all...) The ideal solution would be 1), but I'd neither have the time nor am I very keen on doing it. But if someone else wants to fix it, go ahead. I'd prefer 2) or 3). I use 2.6.x since weeks and I don't have any known problems with it. And if we go for 3), anyone who needs xml_parser_create_ns would have to upgrade to 2.6., otherwise you're just fine with 2.5.x. As nobody reported until now, that xml_parser_create_ns is broken since months, I don't think it's a widely used function anyway. Therefore 4) could also be a solution, 'cause x_p_c_ns works ok, if you're namespace declarations are not too uncommon and if you don't use default namespaces (but if you use namespaces, then the chances are pretty high that you also use default namespaces..). 5) is unacceptable, IMHO. What do you think? chregu On 2/22/04 8:10 PM, Rob Richards wrote: On Sunday 22 February 2004 01:36 pm, Sterling Hughes wrote: Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 In the meantime either add #ifdef configure checks or revert it out. Recognizing default namespaces shouldn't be hard to hack in to the code that was there, it just requires a bit of a rethink, and I believe we're set on supporting libxml2.5, right? I personally would like to keep support for libxml 2.5, just because we know it works correctly and stable with the xml extensions and I for one have had little time to extensively test the xml extensions against 2.6.x. Other than that, I have no other reasons for supporting 2.5 However, I believe the namespace support for SAX wasn't introduced or at least wasn't fixed up until 2.6 so the issue may not be able to be fixed without requiring 2.6 That being said, if everyone really wants to require 2.6 I would be fine with it, but we may possibly be introducing new problems and will not be able to fall back to 2.5. From what I have heard from people running 2.6.x have reported, there have been no problems so far, but not sure how heavily they tested everything. Rob -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
At 14:10 22/02/2004 -0500, Rob Richards wrote: On Sunday 22 February 2004 01:36 pm, Sterling Hughes wrote: Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 In the meantime either add #ifdef configure checks or revert it out. Recognizing default namespaces shouldn't be hard to hack in to the code that was there, it just requires a bit of a rethink, and I believe we're set on supporting libxml2.5, right? I personally would like to keep support for libxml 2.5, just because we know it works correctly and stable with the xml extensions and I for one have had little time to extensively test the xml extensions against 2.6.x. Other than that, I have no other reasons for supporting 2.5 However, I believe the namespace support for SAX wasn't introduced or at least wasn't fixed up until 2.6 so the issue may not be able to be fixed without requiring 2.6 That being said, if everyone really wants to require 2.6 I would be fine with it, but we may possibly be introducing new problems and will not be able to fall back to 2.5. From what I have heard from people running 2.6.x have reported, there have been no problems so far, but not sure how heavily they tested everything. In any case, try and agree to something :) If you don't then maybe we should leave it to post 5.0.0? I gave Rob the green light because I thought it was a minor change without any BC implications... It still seems OK but if we need libxml 2.6 or greater than I guess it's something we should consider. I have no idea of 2.6 availability and stability vs. 2.5. That said, we are aiming for RC1 on March 1st. Maybe it's a chance to reconsider having a bundle with libxml2? I know many disagree but I think maybe we should have two tar files, one with and one without Andi Andi -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
Ok there are 5 different solutions now to this problem 1) fix the code, so that it works with 2.5.x correctly as well 2) make 2.6.x a prerequisite 3) disable xml_parser_create_ns for 2.5.x 4) use broken code for 2.5.x and fixed code for 2.6.x 5) revert to yesterdays situation (broken for all...) The ideal solution would be 1), but I'd neither have the time nor am I very keen on doing it. But if someone else wants to fix it, go ahead. I'd prefer 2) or 3). I use 2.6.x since weeks and I don't have any known problems with it. And if we go for 3), anyone who needs xml_parser_create_ns would have to upgrade to 2.6., otherwise you're just fine with 2.5.x. As nobody reported until now, that xml_parser_create_ns is broken since months, I don't think it's a widely used function anyway. Therefore 4) could also be a solution, 'cause x_p_c_ns works ok, if you're namespace declarations are not too uncommon and if you don't use default namespaces (but if you use namespaces, then the chances are pretty high that you also use default namespaces..). 5) is unacceptable, IMHO. 4 for the short-term, 1 for the long-term. I'll fix it, but I don't have time atm. -Sterling What do you think? chregu On 2/22/04 8:10 PM, Rob Richards wrote: On Sunday 22 February 2004 01:36 pm, Sterling Hughes wrote: Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 In the meantime either add #ifdef configure checks or revert it out. Recognizing default namespaces shouldn't be hard to hack in to the code that was there, it just requires a bit of a rethink, and I believe we're set on supporting libxml2.5, right? I personally would like to keep support for libxml 2.5, just because we know it works correctly and stable with the xml extensions and I for one have had little time to extensively test the xml extensions against 2.6.x. Other than that, I have no other reasons for supporting 2.5 However, I believe the namespace support for SAX wasn't introduced or at least wasn't fixed up until 2.6 so the issue may not be able to be fixed without requiring 2.6 That being said, if everyone really wants to require 2.6 I would be fine with it, but we may possibly be introducing new problems and will not be able to fall back to 2.5. From what I have heard from people running 2.6.x have reported, there have been no problems so far, but not sure how heavily they tested everything. Rob -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
Hello Christian, Sunday, February 22, 2004, 11:59:34 PM, you wrote: Ok there are 5 different solutions now to this problem 1) fix the code, so that it works with 2.5.x correctly as well 2) make 2.6.x a prerequisite 3) disable xml_parser_create_ns for 2.5.x 4) use broken code for 2.5.x and fixed code for 2.6.x 5) revert to yesterdays situation (broken for all...) The ideal solution would be 1), but I'd neither have the time nor am I very keen on doing it. But if someone else wants to fix it, go ahead. I prefer 3. simply add some #id's and be done. If someone fixes it for 2.5 then solution 1) is pretty much nicer - but i doubt anybody has time for that. I'd prefer 2) or 3). I use 2.6.x since weeks and I don't have any known problems with it. And if we go for 3), anyone who needs xml_parser_create_ns would have to upgrade to 2.6., otherwise you're just fine with 2.5.x. As nobody reported until now, that xml_parser_create_ns is broken since months, I don't think it's a widely used function anyway. Therefore 4) could also be a solution, 'cause x_p_c_ns works ok, if you're namespace declarations are not too uncommon and if you don't use default namespaces (but if you use namespaces, then the chances are pretty high that you also use default namespaces..). 5) is unacceptable, IMHO. What do you think? chregu On 2/22/04 8:10 PM, Rob Richards wrote: On Sunday 22 February 2004 01:36 pm, Sterling Hughes wrote: Mmmh too bad, will try to find a solution for libxml2 2.6 I know, it's late in the release process, but the old implementation didn't recognise default namespaces, which broke quite some ext/xml scripts from php4 days and I'd like to have fixed that before 5.0.0 In the meantime either add #ifdef configure checks or revert it out. Recognizing default namespaces shouldn't be hard to hack in to the code that was there, it just requires a bit of a rethink, and I believe we're set on supporting libxml2.5, right? I personally would like to keep support for libxml 2.5, just because we know it works correctly and stable with the xml extensions and I for one have had little time to extensively test the xml extensions against 2.6.x. Other than that, I have no other reasons for supporting 2.5 However, I believe the namespace support for SAX wasn't introduced or at least wasn't fixed up until 2.6 so the issue may not be able to be fixed without requiring 2.6 That being said, if everyone really wants to require 2.6 I would be fine with it, but we may possibly be introducing new problems and will not be able to fall back to 2.5. From what I have heard from people running 2.6.x have reported, there have been no problems so far, but not sure how heavily they tested everything. Rob -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
1) fix the code, so that it works with 2.5.x correctly as well 2) make 2.6.x a prerequisite 3) disable xml_parser_create_ns for 2.5.x 4) use broken code for 2.5.x and fixed code for 2.6.x 5) revert to yesterdays situation (broken for all...) I prefer 3. simply add some #id's and be done. If someone fixes it for 2.5 then solution 1) is pretty much nicer - but i doubt anybody has time for that. As far as I'm concerned 3 is not an option. We are not removing namespace support from PHP5 when PHP4 supports it. Broken in cases no one has reported is better than not supported at all. If libxml2.5 is supported there needs to be some sort of solution for namespaces, 1,2,4 and 5 are all fine by me; I prefer a combo of 1 and 4. It will never work correctly for option 1. Namespaces in SAX was a 2.6 thing (SAX2). Right, but namespaces just need to work as good as they did in PHP4, we can't lose that compatibility. If it works better - bonus. I dont like option 4 as if something is going to be implemented it should work the same regardless of libxml version used (which is why I prefer 3 over 4 - feature only available for 2.6.x and up). It looks like the only thing everyone here can agree on then is make 2.6 required and pray we are not introducing new problems. I prefer not to do this, but it may be the only option that everyone can live with. I'm fine with requiring 2.6, although things could blow up. -Sterling -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
It will never work correctly for option 1. Namespaces in SAX was a 2.6 thing (SAX2). Right, but namespaces just need to work as good as they did in PHP4, we can't lose that compatibility. If it works better - bonus. So what exactly is broken then in comparison to PHP4? From the size of the patch and everything that was replaced, I was assuming quite a bit. And looking at some of the functions added (start_element_ns, etc...) - those are all SAX2 things. Are these needed to get it all working correctly or were those just additional features? If that is the case, then I would definitely agree fixing it for 2.5 is the way to go and not implement the additional features - Arent we in a feature freeze anyways :) I'm fine with requiring 2.6, although things could blow up. Right, that is what I am afraid of as well. As I mentioned I can live with it, but prefer not to do this. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
It will never work correctly for option 1. Namespaces in SAX was a 2.6 thing (SAX2). Right, but namespaces just need to work as good as they did in PHP4, we can't lose that compatibility. If it works better - bonus. So what exactly is broken then in comparison to PHP4? From the size of the patch and everything that was replaced, I was assuming quite a bit. And looking at some of the functions added (start_element_ns, etc...) - those are all SAX2 things. Are these needed to get it all working correctly or were those just additional features? If that is the case, then I would definitely agree fixing it for 2.5 is the way to go and not implement the additional features - Arent we in a feature freeze anyways :) (*) I don't think any of that is actually broken with comparison to PHP4 - I think all that breaks in PHP4 too. PHP4 uses the prefix with namespaces as does PHP5, all these problems are inherent with using namespace prefixes. The default namespace problem may not exist with PHP4 (haven't tried it), but I assume the other problem must. Even if PHP4 did it wrong in ext/xml, we shouldn't actively violate PHP4's compatibility. This is not like domxml which was never stable, we shouldn't break compat, even if we are doing the right thing. -Sterling (*) Wrap the first paragraph with 'As Far As I know,' I haven't tested this. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
On 2/23/04 1:53 AM, Sterling Hughes wrote: It will never work correctly for option 1. Namespaces in SAX was a 2.6 thing (SAX2). Right, but namespaces just need to work as good as they did in PHP4, we can't lose that compatibility. If it works better - bonus. So what exactly is broken then in comparison to PHP4? From the size of the patch and everything that was replaced, I was assuming quite a bit. And looking at some of the functions added (start_element_ns, etc...) - those are all SAX2 things. Are these needed to get it all working correctly or were those just additional features? If that is the case, then I would definitely agree fixing it for 2.5 is the way to go and not implement the additional features - Arent we in a feature freeze anyways :) (*) I don't think any of that is actually broken with comparison to PHP4 - I think all that breaks in PHP4 too. PHP4 uses the prefix with namespaces as does PHP5, all these problems are inherent with using namespace prefixes. The default namespace problem may not exist with PHP4 (haven't tried it), but I assume the other problem must. Even if PHP4 did it wrong in ext/xml, we shouldn't actively violate PHP4's compatibility. This is not like domxml which was never stable, we shouldn't break compat, even if we are doing the right thing. No, it worked right in PHP4 with expat. See php5/ext/xml/xml009.phpt, this test works in PHP4/expat and now in PHP5 with libxml2.6, but not with libxml2.5. Therefore at the moment, with libxml2.5, BC to PHP 4 is broken. I recognized that, when I tried to use HTTP_WebDAV_Server from PEAR (the only package in pear, which uses xml_parser_create_ns, btw) And I didn't introduce new features ;) xml_parser_create_ns() exists since 4.0.5. And the internal implementation is much shorter and much simler now. I'd also prefer if we don't have to bump the requirement to 2.6 at this stage in the release process. If solution 3 (disable it) or 4 (use broken code for 2.5) is the way to go, I don't know. The functions seems not to be used very often, as noone reported any problem with it. But if you would use the broken one, you would soon run into troubles, since a lot of XML files with namespaces use default namespaces and those are not recognized. And this particular issue leads to a very high WTF factor, IMHO. I'd therefore prefer solution 3 in the short term. Fixing it for 2.5 would be even better, of course... And 2.6 as prereq could then be something for 5.1 ;) If noone complains, I'll commit a patch for solution 3 later this morning, so that it at least compiles again with libxml2.5. If solution 4 is preferred, we still can add/revert it later. I don't mind ;) chregu -Sterling (*) Wrap the first paragraph with 'As Far As I know,' I haven't tested this. -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
At 19:25 22/02/2004 -0500, Rob Richards wrote: How much time we looking at between RC1 and a final release? I'd guesstimate a couple of months, around May. Andi -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] cvs: php-src /ext/xml compat.c expat_compat.h
On Sun, 22 Feb 2004, Rob Richards wrote: I'm fine with requiring 2.6, although things could blow up. Right, that is what I am afraid of as well. As I mentioned I can live with it, but prefer not to do this. I've been running with 2.6 since it was out... no weird problems here (but I don't use namespaces). Derick -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
