SOAP_MARSHAL_DATETIME (or: bug #44383)

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

Hi folks,

attached is a patch (with the respective test cases) that implements
DateTime marshalling from and to xsd:dateTime in ext/soap as requested
in http://bugs.php.net/44383

Right now, it is implemented for xsd:date, xsd:time and xsd:dateTime,
but not for other types defined in W3C XML Schema such as gDayMonth; I
don't really think it makes sense mapping from and to DateTimes in
this case (from DateTime to gDayMonth would work, but the other way
round would prove rather difficult).

Some notes about this patch:

it conforms strictly to the XML Schema specification by only
producing canonical representations of values when generating
xsd:dateTime and xsd:time values. Specifically:
- it will not generate trailing zeroes on microseconds (in other
  words, it simply generates a fractional second part as mandated by the
  specification), but it will accept such values
- UTC is always used as the timezone (one of the tests in ext/date/
  tests that mirrors SBR1-echoDate from http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate
  currently does this wrong), but it will accept any timezone
xsd:time produces current date when generating a DateTime object
xsd:date is relatively straightfoward as well:
- produces "00:00:00" as the time when creating a DateTime object
- accepts any time when parsing
- also supports timezones
as a side effect of the patch, microseconds are now supported in
time values (for xsd:time and xsd:dateTime), hence the removed comment
in to_xml_time

The tests have several permutations, but all but one is commented out
each. The test_schema() function does some odd (but understandable)
stunts with output buffering and global variables that make it
impossible to test more than one case at a time. We didn't want to
produce a million test files for the several variants; is there a
nicer way to test this properly?

This feature is enabled by a SoapClient "feature" called
SOAP_MARSHAL_DATETIME. I think this is a reasonable choice.

Greetings,

David

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

bump

Dmitry, did you have a chance to review this patch yet?

David

Hi folks,

attached is a patch (with the respective test cases) that implements
DateTime marshalling from and to xsd:dateTime in ext/soap as
requested in http://bugs.php.net/44383

Right now, it is implemented for xsd:date, xsd:time and
xsd:dateTime, but not for other types defined in W3C XML Schema such
as gDayMonth; I don't really think it makes sense mapping from and
to DateTimes in this case (from DateTime to gDayMonth would work,
but the other way round would prove rather difficult).

Some notes about this patch:

it conforms strictly to the XML Schema specification by only
producing canonical representations of values when generating
xsd:dateTime and xsd:time values. Specifically:

it will not generate trailing zeroes on microseconds (in other
words, it simply generates a fractional second part as mandated by
the specification), but it will accept such values

UTC is always used as the timezone (one of the tests in ext/date/
tests that mirrors SBR1-echoDate from http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate
currently does this wrong), but it will accept any timezone

xsd:time produces current date when generating a DateTime object

xsd:date is relatively straightfoward as well:

produces "00:00:00" as the time when creating a DateTime object

accepts any time when parsing

also supports timezones

as a side effect of the patch, microseconds are now supported in
time values (for xsd:time and xsd:dateTime), hence the removed
comment in to_xml_time

The tests have several permutations, but all but one is commented
out each. The test_schema() function does some odd (but
understandable) stunts with output buffering and global variables
that make it impossible to test more than one case at a time. We
didn't want to produce a million test files for the several
variants; is there a nicer way to test this properly?

This feature is enabled by a SoapClient "feature" called
SOAP_MARSHAL_DATETIME. I think this is a reasonable choice.

Greetings,

David

<
schema089
.phpt

<
soap_marshal_datatype
.diff
.txt

<
schema087
.phpt><schema088.phpt><schema086.phpt><schema090.phpt><schema091.phpt

16 years ago by Dmitry Stogov — view source — reply

unread

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.

The only thing I didn't understood - why win32/php_stdint.h is needed.

Thanks. Dmitry.

David Zülke wrote:

bump

Dmitry, did you have a chance to review this patch yet?

David

Hi folks,

attached is a patch (with the respective test cases) that implements
DateTime marshalling from and to xsd:dateTime in ext/soap as requested
in http://bugs.php.net/44383

Right now, it is implemented for xsd:date, xsd:time and xsd:dateTime,
but not for other types defined in W3C XML Schema such as gDayMonth; I
don't really think it makes sense mapping from and to DateTimes in
this case (from DateTime to gDayMonth would work, but the other way
round would prove rather difficult).

Some notes about this patch:

it conforms strictly to the XML Schema specification by only
producing canonical representations of values when generating
xsd:dateTime and xsd:time values. Specifically:

it will not generate trailing zeroes on microseconds (in other
words, it simply generates a fractional second part as mandated by the
specification), but it will accept such values

UTC is always used as the timezone (one of the tests in
ext/date/tests that mirrors SBR1-echoDate from
http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate currently
does this wrong), but it will accept any timezone

xsd:time produces current date when generating a DateTime object

xsd:date is relatively straightfoward as well:

produces "00:00:00" as the time when creating a DateTime object

accepts any time when parsing

also supports timezones

as a side effect of the patch, microseconds are now supported in
time values (for xsd:time and xsd:dateTime), hence the removed comment
in to_xml_time

The tests have several permutations, but all but one is commented out
each. The test_schema() function does some odd (but understandable)
stunts with output buffering and global variables that make it
impossible to test more than one case at a time. We didn't want to
produce a million test files for the several variants; is there a
nicer way to test this properly?

This feature is enabled by a SoapClient "feature" called
SOAP_MARSHAL_DATETIME. I think this is a reasonable choice.

Greetings,

David

<schema089.phpt><soap_marshal_datatype.diff.txt><schema087.phpt><schema088.phpt><schema086.phpt><schema090.phpt><schema091.phpt

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least
into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.

The only thing I didn't understood - why win32/php_stdint.h is needed.

Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a dependency
on ext/date; I think I had trouble compiling ext/soap as a standalone
extension like this. Must check again. Any hints?

David

16 years ago by Dmitry Stogov — view source — reply

unread

David Zülke wrote:

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final decision.

The only thing I didn't understood - why win32/php_stdint.h is needed.

Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a dependency
on ext/date; I think I had trouble compiling ext/soap as a standalone
extension like this. Must check again. Any hints?

I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

Thanks. Dmitry.

David

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

Dmitry Stogov wrote:

David Zülke wrote:

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.

The only thing I didn't understood - why win32/php_stdint.h is
needed.
Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a
dependency
on ext/date; I think I had trouble compiling ext/soap as a
standalone
extension like this. Must check again. Any hints?
I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

ext/date is not an extension, it's part of core, just like ext/
standard so you shouldn't have any problems with it.

Attached (and also posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383)
is an update of the patch. It has the following updates:

all tests adjusted, reviewed and changed to work in sequence (only
one of the several variants was not commented out before)
fixed handling of unix timestamp longs

There are the following outstanding issues (I'm going on a holiday
tomorrow, so I figured I'd shoot you an update in the meantime):

there seem to be problems with negative timezone offsets (see tests
ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused
at the minute, it breaks ext/soap/tests/schema/schema064.phpt.
Except for one of the cases where the formatting is indeed wrong, it's
due to time zones not being included. That obviously needs fixing, but
I'd like to point out that the current tests do not seem to be in
compliance with the XML Schema specification, which for gMonthDay,
gDay and gMonth states: "An optional following time zone qualifier is
allowed as for date". The rule for "date" and timezone postfixes is
"For timezoned values, append the canonical representation of the
·recoverable timezone·". A recoverable timezone is an offset value in
the format "[+-]hh:mm". http://www.w3.org/TR/xmlschema-2/ has all the
details, but maybe I'm missing something. For gYearMonth and gYear, I
think the "dateTime" timezone rules apply, which means the canonical
representation must always be in UTC (and thus carry "Z" as the
timezone identifier, which is what the tests currently expect, so
those are correct).

Finally, when I compile as an extension, I get the following error
once I reach tests that execute code relying on timelib:

dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

dyld: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

I compiled without --enable-soap, then used the correct "phpize" in
ext/soap, ran configure with the correct --with-php-config=.../blah/
php-config, make install and enabled the extension in php.ini.

Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks.

Cheers,

David

16 years ago by Dmitry Stogov — view source — reply

unread

Hi David,

sorry for delay.

The patch can't be used as it breaks ext/soap build as shared extension.
timelib function are compiled into php and aren't exported :(

May be you will be able to change the patch using ext/date public API.

Also we will need a patch for PHP6 to commit it into both branches, but
it's the second priority.

Thanks. Dmitry.

David Zülke wrote:

Dmitry Stogov wrote:

David Zülke wrote:

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at least
into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.

The only thing I didn't understood - why win32/php_stdint.h is needed.
Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a dependency
on ext/date; I think I had trouble compiling ext/soap as a standalone
extension like this. Must check again. Any hints?
I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

ext/date is not an extension, it's part of core, just like
ext/standard so you shouldn't have any problems with it.

Attached (and also posted here: http://pastie.org/575559 and here:
http://bugs.php.net/44383) is an update of the patch. It has the
following updates:

all tests adjusted, reviewed and changed to work in sequence (only
one of the several variants was not commented out before)

fixed handling of unix timestamp longs

There are the following outstanding issues (I'm going on a holiday
tomorrow, so I figured I'd shoot you an update in the meantime):

there seem to be problems with negative timezone offsets (see tests
ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused

at the minute, it breaks ext/soap/tests/schema/schema064.phpt. Except
for one of the cases where the formatting is indeed wrong, it's due to
time zones not being included. That obviously needs fixing, but I'd like
to point out that the current tests do not seem to be in compliance with
the XML Schema specification, which for gMonthDay, gDay and gMonth
states: "An optional following time zone qualifier is allowed as for
date". The rule for "date" and timezone postfixes is "For timezoned
values, append the canonical representation of the ·recoverable
timezone·". A recoverable timezone is an offset value in the format
"[+-]hh:mm". http://www.w3.org/TR/xmlschema-2/ has all the details, but
maybe I'm missing something. For gYearMonth and gYear, I think the
"dateTime" timezone rules apply, which means the canonical
representation must always be in UTC (and thus carry "Z" as the timezone
identifier, which is what the tests currently expect, so those are
correct).

Finally, when I compile as an extension, I get the following error once
I reach tests that execute code relying on timelib:

dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

dyld: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

I compiled without --enable-soap, then used the correct "phpize" in
ext/soap, ran configure with the correct
--with-php-config=.../blah/php-config, make install and enabled the
extension in php.ini.

Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks.

Cheers,

David

16 years ago by Derick Rethans — view source — reply

unread

The patch can't be used as it breaks ext/soap build as shared extension.
timelib function are compiled into php and aren't exported :(

May be you will be able to change the patch using ext/date public API.

We can also just export them... Which symbols are they?

regards,
Derick

--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr

16 years ago by Dmitry Stogov — view source — reply

unread

Hi Derick,

Derick Rethans wrote:

The patch can't be used as it breaks ext/soap build as shared extension.
timelib function are compiled into php and aren't exported :(

May be you will be able to change the patch using ext/date public API.

We can also just export them... Which symbols are they?

Probably it make sense for the future release. php6?

Thanks. Dmitry.

regards,
Derick

16 years ago by johannes@schlueters.de — view source — reply

unread

We can also just export them... Which symbols are they?

Probably it make sense for the future release. php6?

I think it's quite useful to export timelib as time manipulation is
quite often needed.

In the past we sometimes added new APIs to bug fix releases .. while I
won't advise doing that .. which APIs should be exported to have proper
support?

johannes

16 years ago by Ville Jungman — view source — reply

unread

it would be fun if code recycling was easier. nowadays extracting a
function from code is sometimes complicated if you need to reuse it
elsewhere.

For example you have this ...

while($numbers as $value){
while(...){
while(...){
...
do_something_with($value);
...
}
}
}

... but you would like to use the inner loop also elsewhere. Just
define it as a function ...

while($numbers as $value){
while(...){
while(...){
do_something_with($value);
do_something_with($value + 1);
} as function inner_loop($value);
}
}

... and go ...

inner_loop(3);

Or you have a function below and would like to use only the if-part
elsewhere. Again define that as a function:

function something($value){
something();
foreach(...){
if(...){
do_something_with($value);
do_something_with($value + 1);
} as function snippet($value);
}
something();
}

... and call it ...
snippet(3);

i think it might be useful if all php internal commands returned
some value(s)

something like this could do ...

while(
if($x){
return array(1,2);
}else{
return array(3,4,5);
} as $value
){
do_something_with($value);
}

... or even ...

$selection_array =
while(
if($x){
return array(1,2);
}else{
return array(3,4,5);
} as $value
){
do_something_with($value);
return if($value == 2 || $value == 4){
return $value;
}
}
;

this would make code more straightforward and easier to understand
(when you get used to it). and enables "a maximum degree of
recursivability that can lead to impressive solutions some areas".
also think about pipes in shell.

(the return idea is stolen from postgres pl/pgsql. loop commands
(while, foreach etc) return always arrays.)

see also:
http://www.rebol.net/r3blogs/0024.html
beginners@perl.org/msg47298.html" rel="nofollow" target="_blank">http://www.mail-archive.com/beginners@perl.org/msg47298.html
http://www.postgresql.org/docs/8.0/interactive/plpgsql-control-structures.html

Ville

16 years ago by johannes@php.net — view source — reply

unread

Hi,

please don't abuse another thread for something completely unrelated,
that makes tracking things really hard.
Most of you want should be doable with 5.3's anonymous
functions/closures.
More than that isn't really planned at the moment.

johannes

it would be fun if code recycling was easier. nowadays extracting a
function from code is sometimes complicated if you need to reuse it
elsewhere.

For example you have this ...

while($numbers as $value){
while(...){
while(...){
...
do_something_with($value);
...
}
}
}

... but you would like to use the inner loop also elsewhere. Just
define it as a function ...

while($numbers as $value){
while(...){
while(...){
do_something_with($value);
do_something_with($value + 1);
} as function inner_loop($value);
}
}

... and go ...

inner_loop(3);

Or you have a function below and would like to use only the if-part
elsewhere. Again define that as a function:

function something($value){
something();
foreach(...){
if(...){
do_something_with($value);
do_something_with($value + 1);
} as function snippet($value);
}
something();
}

... and call it ...
snippet(3);

i think it might be useful if all php internal commands returned
some value(s)

something like this could do ...

while(
if($x){
return array(1,2);
}else{
return array(3,4,5);
} as $value
){
do_something_with($value);
}

... or even ...

$selection_array =
while(
if($x){
return array(1,2);
}else{
return array(3,4,5);
} as $value
){
do_something_with($value);
return if($value == 2 || $value == 4){
return $value;
}
}
;

this would make code more straightforward and easier to understand
(when you get used to it). and enables "a maximum degree of
recursivability that can lead to impressive solutions some areas".
also think about pipes in shell.

(the return idea is stolen from postgres pl/pgsql. loop commands
(while, foreach etc) return always arrays.)

see also:
http://www.rebol.net/r3blogs/0024.html
beginners@perl.org/msg47298.html" rel="nofollow" target="_blank">http://www.mail-archive.com/beginners@perl.org/msg47298.html
http://www.postgresql.org/docs/8.0/interactive/plpgsql-control-structures.html

Ville

16 years ago by Richard Lynch — view source — reply

unread

... but you would like to use the inner loop also elsewhere. Just
define it as a function ...

while($numbers as $value){
while(...){
while(...){
do_something_with($value);
do_something_with($value + 1);
} as function inner_loop($value);
}
}

... and go ...

inner_loop(3);

-1

While fun, this is just too esoteric for PHP, imho.

--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

Dmitry Stogov wrote:

David Zülke wrote:

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.

The only thing I didn't understood - why win32/php_stdint.h is
needed.
Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a
dependency
on ext/date; I think I had trouble compiling ext/soap as a
standalone
extension like this. Must check again. Any hints?
I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

ext/date is not an extension, it's part of core, just like ext/
standard so you shouldn't have any problems with it.

Not attached (because the draconian police state filters at
lists.php.net didn't like the patch attachment or something :)), but
posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383
, is an update of the patch. It has the following updates:

all tests adjusted, reviewed and changed to work in sequence (only
one of the several variants was not commented out before)
fixed handling of unix timestamp longs

There are the following outstanding issues (I'm going on a holiday
tomorrow, so I figured I'd shoot you an update in the meantime):

there seem to be problems with negative timezone offsets (see tests
ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused
at the minute, it breaks ext/soap/tests/schema/schema064.phpt.
Except for one of the cases where the formatting is indeed wrong, it's
due to time zones not being included. That obviously needs fixing, but
I'd like to point out that the current tests do not seem to be in
compliance with the XML Schema specification, which for gMonthDay,
gDay and gMonth states: "An optional following time zone qualifier is
allowed as for date". The rule for "date" and timezone postfixes is
"For timezoned values, append the canonical representation of the
·recoverable timezone·". A recoverable timezone is an offset value in
the format "[+-]hh:mm". http://www.w3.org/TR/xmlschema-2/ has all the
details, but maybe I'm missing something. For gYearMonth and gYear, I
think the "dateTime" timezone rules apply, which means the canonical
representation must always be in UTC (and thus carry "Z" as the
timezone identifier, which is what the tests currently expect, so
those are correct).

Finally, when I compile as an extension, I get the following error
once I reach tests that execute code relying on timelib:

dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

dyld: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

I compiled without --enable-soap, then used the correct "phpize" in
ext/soap, ran configure with the correct --with-php-config=.../blah/
php-config, make install and enabled the extension in php.ini.

Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks.

Cheers,

David

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

Dmitry Stogov wrote:

David Zülke wrote:

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.

The only thing I didn't understood - why win32/php_stdint.h is
needed.
Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a
dependency
on ext/date; I think I had trouble compiling ext/soap as a
standalone
extension like this. Must check again. Any hints?
I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

ext/date is not an extension, it's part of core, just like ext/
standard so you shouldn't have any problems with it.

Not attached (because the draconian police state filters at
lists.php.net didn't like the patch attachment or something :)), but
posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383
, is an update of the patch. It has the following updates:

all tests adjusted, reviewed and changed to work in sequence (only
one of the several variants was not commented out before)
fixed handling of unix timestamp longs

There are the following outstanding issues (I'm going on a holiday
tomorrow, so I figured I'd shoot you an update in the meantime):

there seem to be problems with negative timezone offsets (see tests
ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused
at the minute, it breaks ext/soap/tests/schema/schema064.phpt.
Except for one of the cases where the formatting is indeed wrong, it's
due to time zones not being included. That obviously needs fixing, but
I'd like to point out that the current tests do not seem to be in
compliance with the XML Schema specification, which for gMonthDay,
gDay and gMonth states: "An optional following time zone qualifier is
allowed as for date". The rule for "date" and timezone postfixes is
"For timezoned values, append the canonical representation of the
·recoverable timezone·". A recoverable timezone is an offset value in
the format "[+-]hh:mm". http://www.w3.org/TR/xmlschema-2/ has all the
details, but maybe I'm missing something. For gYearMonth and gYear, I
think the "dateTime" timezone rules apply, which means the canonical
representation must always be in UTC (and thus carry "Z" as the
timezone identifier, which is what the tests currently expect, so
those are correct).

Finally, when I compile as an extension, I get the following error
once I reach tests that execute code relying on timelib:

dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

dyld: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

I compiled without --enable-soap, then used the correct "phpize" in
ext/soap, ran configure with the correct --with-php-config=.../blah/
php-config, make install and enabled the extension in php.ini.

Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks.

Cheers,

David

16 years ago by david.zuelke@bitextender.com — view source — reply

unread

Dmitry Stogov wrote:

David Zülke wrote:

Hi David,

I took only a quick look, but I like the patch.
In case it doesn't break any tests, it should be committed at
least into
HEAD. I agree to commit it into 5.3 too, but RMs take the final
decision.

The only thing I didn't understood - why win32/php_stdint.h is
needed.
Ah, yes, that's probably an oversight. Good catch. The headers were
copy-pasted from some ext/date file :)

Another thing that just occured to me is that we now have a
dependency
on ext/date; I think I had trouble compiling ext/soap as a
standalone
extension like this. Must check again. Any hints?
I think ext/date can't be removed or compiled as shared extension.
If it's the case, the only problem may be with unexported symbols.
Just try to compile/test it as shared extension on Linux and Windows.

ext/date is not an extension, it's part of core, just like ext/
standard so you shouldn't have any problems with it.

Not attached (because the draconian police state filters at
lists.php.net didn't like the patch attachment or something :)), but
posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383
, is an update of the patch. It has the following updates:

all tests adjusted, reviewed and changed to work in sequence (only
one of the several variants was not commented out before)
fixed handling of unix timestamp longs

There are the following outstanding issues (I'm going on a holiday
tomorrow, so I figured I'd shoot you an update in the meantime):

First, there seem to be problems with negative timezone offsets (see
tests ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused

Second, at the minute, it breaks ext/soap/tests/schema/schema064.phpt.
Except for one of the cases where the formatting is indeed wrong, it's
due to time zones not being included.
That obviously needs fixing, but I'd like to point out that the
current tests do not seem to be in compliance with the XML Schema
specification, which for gMonthDay, gDay and gMonth states: "An
optional following time zone qualifier is allowed as for date".
The rule for "date" and timezone postfixes is "For timezoned values,
append the canonical representation of the ·recoverable timezone·". A
recoverable timezone is an offset value in the format "[+-]hh:mm". http://www.w3.org/TR/xmlschema-2/
has all the details, but maybe I'm missing something.
For gYearMonth and gYear, I think the "dateTime" timezone rules apply,
which means the canonical representation must always be in UTC (and
thus carry "Z" as the timezone identifier, which is what the tests
currently expect, so those are correct).

Finally, when I compile as an extension, I get the following error
once I reach tests that execute code relying on timelib:

dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

dyld: Symbol not found: _timelib_time_ctor
Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so
Expected in: flat namespace

I compiled without --enable-soap, then used the correct "phpize" in
ext/soap, ran configure with the correct --with-php-config=.../blah/
php-config, make install and enabled the extension in php.ini.

Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks.

Cheers,

David