phpxmlrpc-devel — Discussion list for developers on XML-RPC for PHP

Re: [phpxmlrpc-devel] [Fwd: XMLRPC Class]

[maHo <lu...@ma...>]

U=C5=BCytkownik Edd Dumbill napisa=C5=82:
> -----Forwarded Message-----
[ciach]

I think that it's interesting proposition (I have no way to test it now=
,=20
but if it works as expected, I think that it would be included into the=
=20
official project).

Hoever, maybe developers consider to split xmlrpc(s).inc into=20
few/several modules?. Big source files in current state aren't very eas=
y=20
to read and analyze.

regards

maHo

[phpxmlrpc-devel] [Fwd: XMLRPC Class]

[Edd D. <ed...@us...>]

-----Forwarded Message-----
From: Laurent GROUSSET <lau...@te...>
To: ed...@us...
Subject: XMLRPC Class
Date: Tue, 16 Dec 2003 15:03:42 +0100



Hy,

=20

Well i have use your usefull XMLRPC class =E2=80=A6

But i need to specify an idsession to connect to the server.

=20

So i modify you class. You can catch it in the attached file.

=20

I=E2=80=99ve just add this in the xmlrpc_client class :

=20

            var $sid=3D'';

           =20

            function setSessionID($thisSID)

            {

                        $this->sid=3D$thisSID;

            }

=20

=20

And this to the sendPayloadHTTP10 methode o:

=20

$credentials=3D'';

                        if ($username!=3D'')

                        {

                                   $credentials=3D'Authorization: Basic '
. base64_encode($username . ':' . $password) . "\r\n";

                        }

                       =20

                        if ($this->sid!=3D'')

                        {

                                   $credentials.=3D'Cookie: sid=3D' .
$this->sid . "\r\n";

                        }

=20

                        $op=3D "POST " . $this->path. "
HTTP/1.0\r\nUser-Agent: PHP XMLRPC 1.0\r\n" .

                                   "Host: ". $this->server  . "\r\n" .

                                   $credentials .=20

                                   "Content-Type:
text/xml\r\nContent-Length: " .

                                   strlen($msg->payload) . "\r\n\r\n" .

                                   $msg->payload;

=20

I hope i twill be usefull for you.

=20

Best regards.

=20

Laurent

R: [phpxmlrpc-devel] xmlrpc and sessions?

[Dylan M. <dy...@ex...>]

> Sorry if this sounds a bit too harsh, but phpxmlrpc is a lib that aims 
> =
> to conform to a spec. The spec, albeit sporting quite a few =
> shortcomings, has been "cast in stone" (in the wording of its  writer) 
> =
> since 1999. A little (much needed) clarification has been added this =
> summer, that's all.

It's not harsh at all.

It sounds like SOAP isn't nearly as cast in stone as XMLRPC is, though,
which sounds funny, because SOAP is a w3c standard, while I don't think
XMLRPC is.  The reason I say this is that Cookie-based sessions in SOAP
seem to be being adopted, even though they're not in the w3c document.

I'm not doing anything .net, but I found that discussion of cookie-based
sessions in a Microsoft .net discussion of SOAP.

However, I can tell when I'm trying to swim up-stream, so after sleeping
on it, I'll just add an SID as an argument to every XMLRPC method I
define.

dylan

R: [phpxmlrpc-devel] xmlrpc and sessions?

[Gaetano G. <giu...@se...>]

>=20
> Since I prefer not to clutter my code with SID's, I'm going to go
> ahead and add cookies to phpxmlrpc.  If I get it in cleanly,
> I'll send it to the list. Those not interested don't have to use
> it. :)
>=20

Sorry if this sounds a bit too harsh, but phpxmlrpc is a lib that aims =
to conform to a spec. The spec, albeit sporting quite a few =
shortcomings, has been "cast in stone" (in the wording of its  writer) =
since 1999. A little (much needed) clarification has been added this =
summer, that's all.

I doubt very much anybody would be willing to include custom =
functionality in the default release of the library, since this =
functionality would not be implemented by any other xml-rpc library (and =
there are many of them out there, from php to c++ to whatever you might =
think of).

Of course, any code contribution is welcome by people that have to =
develop both client and server sides of an app and do not care about =
portability.

All in all, if you're woring in .net, you'll be surely better off using =
SOAP. The same probably also applies if you're working with other =
languages but need the kind of extra functionality that xml-rpc misses.

My 2c.

Gaetano

Re: [phpxmlrpc-devel] xmlrpc and sessions?

[Dylan M. <dy...@ex...>]

Mach wrote:

> Cookies have sense only in webbrowser<->webserver connection.
> xmlrpc is used to link application<->application.
> So I don't think that xmlrpc can support cookies. It have no sense.

I just read up on how .net implements SOAP (XMLRPC's half-brother) --
and found this comment:

"ASP.NET session state is maintained by using one of two underlying
mechanisms. The first is by using HTTP cookies. "
(the second one is by URL-rewriting.) this is from:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
dnservice/html/service08062002.asp

Cookies are, in fact, an integral part of the HTTP spec, so as
long as XMLRPC is being transported via HTTP, they are a viable
alternative.

Since I prefer not to clutter my code with SID's, I'm going to go
ahead and add cookies to phpxmlrpc.  If I get it in cleanly,
I'll send it to the list. Those not interested don't have to use
it. :)

thanks for the reply!
dylan
(ps: one more question on the way...)

Re: [phpxmlrpc-devel] xmlrpc and sessions?

[M. <lu...@ma...>]

On Wed, 10 Sep 2003 13:23:47 -0700, Dylan McNamee wrote
> What is the recommended procedure for developing a session-like 
> XMLRPC protocol? I can imagine using cookies, or an explicit 
> SessionID arg to each procedure. Anyone have experience doing this?
> 
> It doesn't look as though phpxmlrpc handles cookies at the moment. 
> Is this lack of cookie support a part of the xmlrpc standard, or a 
> (momentary) shortcoming of phpxmlrpc? I say momentary because I'm in 
> the process of implementing it, but will halt these efforts if this 
> isn't the recommended way to go.
> 
> thanks!
> dylan
> 

Cookies have sense only in webbrowser<->webserver connection.
xmlrpc is used to link application<->application. 
So I don't think that xmlrpc can support cookies. It have no sense.

IMHO You have to use SID as arg to each procedure.

pozdrav

maHo
--
lukasz shift-2 mach.com.pl,http://www.lukasz.mach.com.pl
gg://1612670 jabber://ma...@ja... jabber://ma...@ja...
icq://136281200 motto://"nie dziel skarbu póki smok zipie"

[phpxmlrpc-devel] xmlrpc and sessions?

[Dylan M. <dy...@ex...>]

What is the recommended procedure for developing a session-like XMLRPC 
protocol?
I can imagine using cookies, or an explicit SessionID arg to each 
procedure.
Anyone have experience doing this?

It doesn't look as though phpxmlrpc handles cookies at the moment. Is 
this lack
of cookie support a part of the xmlrpc standard, or a (momentary) 
shortcoming of
phpxmlrpc? I say momentary because I'm in the process of implementing 
it, but
will halt these efforts if this isn't the recommended way to go.

thanks!
dylan

[phpxmlrpc-devel] [Fwd: Modification to xmlrpc_encode to support associative and sequential arrays]

[Edd D. <ed...@us...>]

-- 
Edd Dumbill.  More from me at <http://usefulinc.com/edd/blog>
Managing Editor, XML.com, XMLhack.com; Chair, XML Europe 2003

R: R: R: [phpxmlrpc-devel] proper data encoding in string value

[Gaetano G. <giu...@se...>]

Oops, forgot the code. here it is.

Included also another (dumb dumb dumb) lib I made for logging requests =
to the xmlrpc server.

Gaetano

R: R: R: [phpxmlrpc-devel] proper data encoding in string value

[Gaetano G. <giu...@se...>]

...
>=20
> 	you're probably right. my patch works well for me, but=20
> if someone add
> functionality you mentioned, i'll be glad. :)
> [ciach]
...

Ok, here's some preliminary code.

Rather than fixing xmlrpcs.inc I preferred to extend the server class, =
overriding base functions.

There are a lot more changes in there other than the char encoding =
stuff, feel free to keep them or rip them off (most of these I submitted =
as patches to sourceforge already):
- ability to block xmlrpc-server to respond to non-https request
- ability to disable all system.xxx functions
- some smarter checking for producing valid comments in xml returned to =
client

About encoding: now the server can
- decide which encodings are accepted. Default: iso-8859-1 and utf-8 =
only
- decide the encoding used for the response.
  Specifically it can use:
  + no encoding specification at all
  + always the same fixed encoding
  + the same encoding as used by the current request
  + the same encoding as per the $xmlrpc_defencoding global variable

Note that setting a specified encoding does actually NOT (trans)encode =
the outgoing message. It only adds a charset-encoding declaration in =
http and xml headers.
In other words, if your server functions do return accented chars and =
the server response-encoding is set to utf-8, the client is likely to =
get some garbled data.

To achieve this extra result, i.e. automatic conversion of the server =
output to the desired encoding, the serialize methods in xmlrpc have to =
be fixed (adding maybe a call to mb_convert_encoding after having =
serialized the whole msg ??? assuming that the originating encoding used =
to set xmrpc values is known).

One more thing to do would be to move the guess_charset_encoding() =
function into xmlrpc.inc, so that it can be used by the client too. This =
would allow it to cope with server responses given in different =
encodings than the request was sent out with, much as the server does.

The new xmlrpc error constat should be moved to xmlrpc.inc, too.

Phew, that was a long mail.
If you're still reading past this point, PLEASE give this cod a try, or =
at least tell me if You think I'm heading down a senseless path. I'm not =
too confident in my ereg skills, and trying to understand all the =
implications of intermingled UNICODE, HTTP, XML and RPC specs is =
somewhat daunting.

Bye, gaetano

Re: R: R: [phpxmlrpc-devel] proper data encoding in string value

[maHo <lu...@ma...>]

[ciach]
>=20
> The way I understand it, iso8859-1, utf-8 and us-ascii are supported
> by PHP xml parser. Allowing to pick between iso and utf then does
> make sense (intentionally forgetting ascii). Plus if future versions
> of PHP allow even more encodings the lib will have the framework
> ready for them.

	you're probably right. my patch works well for me, but if someone add
functionality you mentioned, i'll be glad. :)
[ciach]
>=20
>=20
> Sorry for my ignorance, but AFAIK XML 1.0 states that :
>=20
> - char data comprises "any Unicode character, excluding the surrogate
> blocks, FFFE, and FFFF." - "The right angle bracket (>) may be
> represented using the string ">", and must, for compatibility, be
> escaped using ">" or a character reference when it appears in the
> string "]]>" in content, when that string is not marking the end of a
> CDATA section."
>=20
> so I would not explicitly say that xmlrpc string element is
> binary-safe. (Or am I wrong?)

	hmm, i read that at http://www.xmlrpc.org/spec/ :

# What characters are allowed in strings? Non-printable characters? Nul=
l
characters? Can a "string" be used to hold an arbitrary chunk of binary
data?

Any characters are allowed in a string except < and &, which are encode=
d
as &lt; and &amp;. A string can be used to encode binary data.

so maybe we a reading different specs for one protocol :]

[ciach]
>=20
>=20
> I never actually tried  the builtin functions, since the phpxmlrpc
> lib always worked fine for me, and I have a little bit of code
> deployed already. Of course builtin functions: -should be faster and
> -get much wider exposure. It is a possibility that phpxlrpc will
> slowly be abandoned. In fact I feel there has not been much activity
> since release 1.0.99, even though there are some patches / bugs
> reported.

yeah..., sad..

pozdrav

maHo


--=20
lukasz shift-2 mach.com.pl,http://www.lukasz.mach.com.pl=09
gg://1612670 jabber://ma...@ja...	jabber://ma...@ja...
icq://136281200 motto://"nie dziel skarbu p=F3ki smok zipie"

Re: R: [phpxmlrpc-devel] proper data encoding in string value

[maHo <lu...@ma...>]

> A little while ago I posted to the list a proposal (well, some
> questions, rather than a patch, actually) for variable XML encoding.=20
> In short: some people might need UTF-8 and some people might need
> iso-whatever. Moreover, using default encoding of UTF-8 is not in
> accordance with RFC2616 (afaik), so we actually have a problem. (see
> posting dated 25/9/02)
>=20
> Instead of just reversing the $xmlrpc_defencoding var, a better
> solution would be to make it a property of the client (or message ?)
> class, so that it can be switched 'on the fly'.

	good idea, but builtin xml parser doesn't support encodings other that=
=20
iso8859-1, so mentioned option won't help, but can be very confusing.
	but if default encoding is iso8859-1, and optional UTF8, then IMHO if=20
would be good solution.

>=20
> On the other end of the tunnel, xmlrpc servers should be allowed to
> decide which encoding they accept. The best option would be of course
> if the server could accept more than one encoding, and maybe reply to
> messages using the same encoding as received, 'guessing' it by
> peering at 1-the HTTP headers, 2-the <?xml> tag.
>=20
> I did not propose an implementation for the above because my
> understanding of the xml syntax is too little for point 2 above.
>=20
>=20
> As for not transalting stuff inside <string> except for '<' and '&',
> you also have to make sure that you're 'translating' chars that are
> not valid in the chosen encoding.

	conforming to XMLRPC-spec, translated chars don't need to be in
choosen charset. and the fact is, that in iso-8859-1 all chars, even=20
binary data is encoded and decoded properly.

I know that's a little tricky, but if xml parser doesn't behave=20
properly, this is IMHO a must.

>=20
> One little note: php is quite limited in xml encodings supported
> because of the underlying xml library (expat). Luckily the next
> version (php 5) will use by default XML-lib, wich is much more
> powerful/advanced in many ways.

	BTW. i heard that builtin xmlrpc functions, which are now in=20
experimental state, are quite powerful, so maybe phpxmlrpc will be=20
unneccesary in the future.

regards

maHo
--=20
lukasz shift-2 mach.com.pl,http://www.lukasz.mach.com.pl=09
gg://1612670 jabber://ma...@ja...	jabber://ma...@ja...
icq://136281200 motto://"nie dziel skarbu p=F3ki smok zipie"

R: [phpxmlrpc-devel] proper data encoding in string value

[Gaetano G. <giu...@se...>]

A little while ago I posted to the list a proposal (well, some =
questions, rather than a patch, actually) for variable XML encoding.
In short: some people might need UTF-8 and some people might need =
iso-whatever.
Moreover, using default encoding of UTF-8 is not in accordance with =
RFC2616 (afaik), so we actually have a problem. (see posting dated =
25/9/02)

Instead of just reversing the $xmlrpc_defencoding var, a better solution =
would be to make it a property of the client (or message ?) class, so =
that it can be switched 'on the fly'.

On the other end of the tunnel, xmlrpc servers should be allowed to =
decide which encoding they accept. The best option would be of course if =
the server could accept more than one encoding, and maybe reply to =
messages using the same encoding as received, 'guessing' it by peering =
at 1-the HTTP headers, 2-the <?xml> tag.

I did not propose an implementation for the above because my =
understanding of the xml syntax is too little for point 2 above.


As for not transalting stuff inside <string> except for '<' and '&', you =
also have to make sure that you're 'translating' chars that are not =
valid in the chosen encoding.

One little note: php is quite limited in xml encodings supported because =
of the underlying xml library (expat).
Luckily the next version (php 5) will use by default XML-lib, wich is =
much more powerful/advanced in many ways.

Gaetano

> -----Messaggio originale-----
> Da: php...@li...
> [mailto:php...@li...]Per conto di maHo
> Inviato: domenica 8 giugno 2003 2:40
> A: php...@li...
> Oggetto: [phpxmlrpc-devel] proper data encoding in string value
>=20
>=20
> there is a problem in encoding string value to xmlrpcval.
>=20
> original code uses htmlentities, which converts chars>0x127
> to &someentity; format. this format doesn't stand well
> with php xml parser, and disaster is ready, if there is
> a must to transfer some letters, ie. from polish alphabet.
>=20
> solutions:
> 1)the xmlrpc spec says that only '<' and '&' characters
> need to be translated to entities.
> so strtr($body,array("<"=3D>"&lt;,"&"=3D>"&amp;")) instead of
> htmlentities($body) is better IMHO.
>=20
> 2)changing default encoding from "UTF-8" to
> "iso-8859-1" helps a lot. I don't know why, it's very strange, (as=20
> strange is fact,that php provides only iso8859-1 and utf8 encodings)
>   but with mentioned changes, you can transfer all data, even binary,
> as xmlrpc string.
>=20
> i've posted the proper patch at
>=20
> http://sourceforge.net/tracker/download.php?group_id=3D34455&ati
d=3D411302&file_id=3D52440&aid=3D750764


pozdrav

maHo
--=20
lukasz shift-2 mach.com.pl,http://www.lukasz.mach.com.pl=09
gg://1612670 jabber://ma...@ja...	jabber://ma...@ja...
icq://136281200 motto://"nie dziel skarbu p=F3ki smok zipie"




-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
phpxmlrpc-devel mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/phpxmlrpc-devel

[phpxmlrpc-devel] proper data encoding in string value

[maHo <lu...@ma...>]

there is a problem in encoding string value to xmlrpcval.

original code uses htmlentities, which converts chars>0x127
to &someentity; format. this format doesn't stand well
with php xml parser, and disaster is ready, if there is
a must to transfer some letters, ie. from polish alphabet.

solutions:
1)the xmlrpc spec says that only '<' and '&' characters
need to be translated to entities.
so strtr($body,array("<"=3D>"&lt;,"&"=3D>"&amp;")) instead of
htmlentities($body) is better IMHO.

2)changing default encoding from "UTF-8" to
"iso-8859-1" helps a lot. I don't know why, it's very strange, (as=20
strange is fact,that php provides only iso8859-1 and utf8 encodings)
  but with mentioned changes, you can transfer all data, even binary,
as xmlrpc string.

i've posted the proper patch at

http://sourceforge.net/tracker/download.php?group_id=3D34455&atid=3D411=
302&file_id=3D52440&aid=3D750764


pozdrav

maHo
--=20
lukasz shift-2 mach.com.pl,http://www.lukasz.mach.com.pl=09
gg://1612670 jabber://ma...@ja...	jabber://ma...@ja...
icq://136281200 motto://"nie dziel skarbu p=F3ki smok zipie"

[phpxmlrpc-devel] Is it better to catch fsockopen timeout errors?

[Gaetano G. <giu...@se...>]

Since we're providing error codes in the xmlrpc response, it might be a =
good idea to catch the error messages generated by timeout on socket =
connections. (i.e. replace fsockopen with @fsockopen in xmlrpc.inc)

This applies e.g. on a website that has display turned on for all php =
errors, and does only check the result of $msg->send() for any problem: =
the error will be handled correctly, but on the webpage will be =
displayed the fsockopen error messages anyway.

Ciao,
Gaetano

[phpxmlrpc-devel] Empty lines patch

[Dougal C. <do...@gu...>]

While playing with Scott Andrew LePera's pubsub experiments[1], we ran
across a problem in the XML-RPC library. At first, we thought it was
caused by Scott including a <!-- comment --> in his XML response, but I
finally tracked down the real source of the problem, which was extra
whitespace between the response's headers and content.

I've attached a diff file to work around this problem. I made two minor
changes. First, it uses preg_split() instead of just split(), in order
to catch the possibility of lines ending in just '\n' instead of '\r\n'.
This is in order to follow the tenet of "be generous in what you
receive, strict in what you send". Next, it checks for any empty
elements at the beginning of the $ar before joining them into the $data
array, because otherwise, the call to xml_parse will choke.

[1] http://www.scottandrew.com/main/2003_05#a000658

-- 
Ernest MacDougal Campbell III, MCP+I, MCSE <do...@gu...>
http://dougal.gunters.org/             http://spam.gunters.org/
  Web Design & Development:  http://www.mentalcollective.com/
       This message is guaranteed to be 100% eror frea!

[phpxmlrpc-devel] line 333

[Oliver M. <dow...@ho...>]

Hello there

=20

XML-RPC with PHP 4.2.3 and Apache 1.3.27(Win32) on Win2k SP3.

I got the following notice on the http: Undefined index: ac in =
xmlrpc.inc on line 333. And the following warning: Can't add header =
information - headers already sent by (output started at xmlrpc.inc:333) =
in xmlrpcs.inc on line 178.
I added the following peace of code at line 333, as described in the =
book "professional php4 xml" from wrox (see page 650): =
if(!isset($_xh[$parser]['ac'])){$_xh[parser]['ac']=3D'';}. But it =
doesn't help. I still got the same notice and warning.
Who can help?

[phpxmlrpc-devel] Getting started

[Oliver M. <dow...@ho...>]

Hello

=20

I try to get a small "Hello, World!" XML-RPC application running on my =
little intranet. But it doesn't work. I installed Apache 2.0.43(Win32) =
and PHP 4.2.3 on Win2k.

=20

I got the following errors:

=20

            Running only the server:

faultCode 103, faultString XML error: no element found at line 1

=20

            Running the client:

errno 9, errstr : Bad file descriptor

=20

And there is this problem with the apache server. If I use the send =
method from the client ($result =3D $client->send($message, 40);) it is =
not always possible to refresh the page. The server is not able to =
complete the request.

=20

I tried some examples from the books xml-rpc from O'Reily and =
Professional PHP4 XML from wrox. But non of them works.

=20

Who can help. I tried already for hours.

[phpxmlrpc-devel] steam timeout

[lukasz m. <lu...@ma...>]

hello

i'm still working on project using phpxmlrpc.

i'm retrieving very large data via xmlrpc, and there is problem with socket 
timeout(default 60).

of course, it's possible to change option in php.ini, but it isn't always desired.

so i think there is need to set socketstream timeout independent of set connection timeout.

i'm sending appropriate patch


-- 
lukasz shift-2 mach.com.pl,http://www.lukasz.mach.com.pl	
gg://1612670 jabber://ma...@ja...	icq://136281200
motto://"kto rano wstaje, ten leje jak z cebra"

R: R: R: [phpxmlrpc-devel] is this list working?

[Gaetano G. <giu...@se...>]

[SNIP]

>=20
> > If you are developing a server open to public usage it=20
> > might not look very 'clean', but then you're better off=20
> > sticking to the protocol as much as you can anyway ...
> > yes, you're right.

> another option: influence xmlrpc spec to allow scientific=20
> format. but how, i don't know yet.
>=20

Sorry, but this is not an option.
If you dig a bit in the xml-rpc mailing list, then you'll see that Dave =
Winer (spec author and copyright holder of the name) has a fairly =
precise opinion on it: xml-rpc is 'cast in stone'. He won't even allow =
changes in the wording of the spec that would clarify =
long-(long)-standing issues (such as: is ISO-DATETIME meant to be a full =
ISO confomant representation or is the only valid format for dates the =
one specified in the example? etc...).
Some people even started out their own 'improved' version of the =
protocol (e.g. xml-rpc over e-mail), but I dunno if those dialects are =
still growing or plain dead.

Re: R: R: [phpxmlrpc-devel] is this list working?

[lukasz m. <lu...@ma...>]

Gaetano Giunta wrote:
[ciach]

> Another option would be to simply encode/decode the scientific-formatted values as strings, and do the conversion inside the application.
> If you're developing a private app there's no problem, since you build both client & server.

	i'm developing private app, but i do recognize by type, an 
another action is taken for string, and another for double.
	i think i must use something like
<struct>
<member><name>type</name><value>scientific</value></member>
<member><name>value</name><value>1.3e200</value></member>
</struct>

instead of <double>1.3e200</double>

sad. all simplicity goes to hell.....

> If you are developing a server open to public usage it might not look very 'clean', but then you're better off sticking to the protocol as much as you can anyway ...
yes, you're right.
another option: influence xmlrpc spec to allow scientific 
format. but how, i don't know yet.


regards

maHo

R: R: [phpxmlrpc-devel] is this list working?

[Gaetano G. <giu...@se...>]

...
>=20
> and problem is, how to code VERY BIG float to non-scientific=20
> format. simply sprintf(%f,$number) seems to be not working=20
> properly.
>=20
> printf("%f",1.3e200) produces=20
> 12999999999999977000000000000000000000000000000000000000000000
> 00000000000000000.00000000
> which is near 1.3e78.
>=20
> 1.3e200 should by inside double range.
>

max float =3D	+3.4028235e38
max double =3D  +1.7976931348623157e308
[I found these values somewhere on the net other than the C(glibc?) =
spec, so I'm not too confident:]

>=20
> so maybe we should consider allow to use scientific format?
>=20

Another option would be to simply encode/decode the scientific-formatted =
values as strings, and do the conversion inside the application.
If you're developing a private app there's no problem, since you build =
both client & server.
If you are developing a server open to public usage it might not look =
very 'clean', but then you're better off sticking to the protocol as =
much as you can anyway ...

regards,
Gaetano

Re: R: [phpxmlrpc-devel] is this list working?

[Ryan H. <rh...@is...>]

lukasz mach wrote:

> Gaetano Giunta wrote:
>
>> A very large amount of data indeed, but it is the only way to go!
>
> and problem is, how to code VERY BIG float to non-scientific format. 
> simply sprintf(%f,$number) seems to be not working properly.
>
> printf("%f",1.3e200) produces 
> 1299999999999997700000000000000000000000000000000000000000000000000000000000000.00000000 
>
> which is near 1.3e78.
>
> 1.3e200 should by inside double range.
>
> so maybe we should consider allow to use scientific format?

 From an interoperability standpoint, this seems wrong.  I would suggest 
handling scientific notation at the application layer instead of the RPC 
layer.  Use a string and do validation within your app.

--
Ryan Hoegg
Contributor, Apache XML-RPC project

Re: R: [phpxmlrpc-devel] is this list working?

[lukasz m. <lu...@ma...>]

Gaetano Giunta wrote:
>>so i'm wondering if those mail successfull arrived to list.
>>
> 
> 
> yes, it deed

	funny, when i asked this question, suddenly both mails 
(last and those about floats) appeared on sourceforge.
maybe there is some kind of buffer, which have to be 
overflowed to appear message on board?

> 
> 
>>had anybody read mail about float/double numbers encoding?
>>
> 
> 
> I am in no way a major developer of the lib, here's my take anyway:
> 
> 
>>there is a problem with very big(or very small) float 
>>numbers. php automagically converts it to scientific number
>>for example
>>	1300000000000000000000 to 1.3e21
>>
>>xmlrpc server accepts it as valid double value, but xmlrpc 
>>client "converts" it to ERROR_NON_NUMERIC_FOUND, because it 
>>doesn't match to "^[0-9\+\-\.]+$" regexp.
>>	i see 2 solutions:
>>1) let php server accept scientific format, and replace 
>>regexp based check by is_float(). but xmlrpc specification 
>>is unclear for me, and i'm not sure if it allow scientific 
>>format of double number.
>>
> 
> 
> The spec is deceptively simple in many places, here's the concerning paragraph:
> 
>   # What is the legal syntax (and range) for floating point values (doubles)? How is the exponent represented? How to deal with whitespace?  Can infinity and "not a number" be represented?
> 
>   There is no representation for infinity or negative infinity or "not a number". At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified.
> 
> As far as my understanding goes, NO scientific notation allowed.

	it isn't forbidden explicit. but it looks like you're right.

[ciach]
> 
>>2) convert every big or small double to normal format using 
>>sprintf and proper precision modifier. but it can generate 
>>amount of unneeded data (1.3e55 takes 6 bytes, 13000....0000 
>>takes 56 bytes).
>>
> 
> 
> A very large amount of data indeed, but it is the only way to go!

and problem is, how to code VERY BIG float to non-scientific 
format. simply sprintf(%f,$number) seems to be not working 
properly.

printf("%f",1.3e200) produces 
1299999999999997700000000000000000000000000000000000000000000000000000000000000.00000000
which is near 1.3e78.

1.3e200 should by inside double range.


so maybe we should consider allow to use scientific format?

regards

maHo

I: [phpxmlrpc-devel] is this list working?

[Gaetano G. <giu...@se...>]

> >=20
> > so i'm wondering if those mail successfull arrived to list.
> >=20
>=20
> yes, it deed
>=20
> > had anybody read mail about float/double numbers encoding?
> >=20
>=20
> I am in no way a major developer of the lib, here's my take anyway:
>=20
> > there is a problem with very big(or very small) float=20
> > numbers. php automagically converts it to scientific number
> > for example
> > 	1300000000000000000000 to 1.3e21
> >=20
> > xmlrpc server accepts it as valid double value, but xmlrpc=20
> > client "converts" it to ERROR_NON_NUMERIC_FOUND, because it=20
> > doesn't match to "^[0-9\+\-\.]+$" regexp.
> > 	i see 2 solutions:
> > 1) let php server accept scientific format, and replace=20
> > regexp based check by is_float(). but xmlrpc specification=20
> > is unclear for me, and i'm not sure if it allow scientific=20
> > format of double number.
> >=20
>=20
> The spec is deceptively simple in many places, here's the=20
> concerning paragraph:
>=20
>   # What is the legal syntax (and range) for floating point=20
> values (doubles)? How is the exponent represented? How to=20
> deal with whitespace?  Can infinity and "not a number" be represented?
>=20
>   There is no representation for infinity or negative=20
> infinity or "not a number". At this time, only decimal point=20
> notation is allowed, a plus or a minus, followed by any=20
> number of numeric characters, followed by a period and any=20
> number of numeric characters. Whitespace is not allowed. The=20
> range of allowable values is implementation-dependent, is not=20
> specified.
>=20
> As far as my understanding goes, NO scientific notation allowed.
> In fact the regexp above looks a bit too wide: to stick=20
> closely to the spec ^[\+\-][0-9]*\.[0-9]*$ could be more appropriate.
> btw: this excludes values as "1" or "1.0" but allows for=20
> "+.5", "+1." or even "+."
> If we take 'any number' in the spec to mean 1 or more then=20
> the regexp would of course be ^[\+\-][0-9]+\.[0-9]+$
>=20
> As a sidenote, the lib uses in fact "^\-?[0123456789 \t\.]+$"=20
> regexp to validate both INT and DOUBLE types.
> THIS IS QUITE WRONG, since the spec paragraph concerning int=20
> values reads:
>=20
>   # What is the legal syntax (and range) for integers? How to=20
> deal with leading zeros? Is a leading plus sign allowed? How=20
> to deal with whitespace?
>=20
>   An integer is a 32-bit signed number. You can include a=20
> plus or minus at the beginning of a string of numeric=20
> characters. Leading zeros are collapsed. Whitespace is not=20
> permitted. Just numeric characters preceeded by a plus or minus.
>=20
> The correct regexp for integers is then: [\+\-]?0*[0-9]{1,10}=20
> or maybe simply [\+\-]?[0-9]{1,10}
>=20
> Of course, there is always the option to let the library be=20
> forgiving and accept a wider range of values than stated in=20
> the the spec (while emitting conforming values only).
> But using a bad validation (as the lib does now) is IMHO=20
> scarcely better than doing no validation at all...
>=20
> > 2) convert every big or small double to normal format using=20
> > sprintf and proper precision modifier. but it can generate=20
> > amount of unneeded data (1.3e55 takes 6 bytes, 13000....0000=20
> > takes 56 bytes).
> >=20
>=20
> A very large amount of data indeed, but it is the only way to go!
>=20
> Bye, Gaetano
>=20