Hi,
this was sent to xmlrpc-user. Sorry!
Jochen
---BeginMessage---
Hi,
I would like to suggest the following patch for the XmlRpcServer docs.
The current statement is, IMO, misleading. Suggest the following:
- Thread A invokes addHandler(name, something);
- Thread B invokes
Hi,
I understand that the spec doesn't handle null values. As xml-rpc
implements the SPEC, I find it completely valid, that null values are
rejected *by default*. However, I can think of no reason why they
shouldn't be supported *as a vendor extension*. Most of the other Apache
software
On Di, 2004-06-15 at 19:01, Ryan Bloom wrote:
So, I have one option (which kind of sucks), I can cast the byte[] to an
Object in the calls to encode/decode to retain compatibility between codec
1.1 and 1.2.
Let it suck. :-) If you do that change, it will prevent a lot of hazzle
and
Hi,
the following makes the jar target create a file called
xmlrpc-version-src.zip as well. This file contains the sources.
The reason for doing so is, that such files are quite convenient for
attaching them to the Java debugger. For example, in Eclipse I am always
adding the jar file and the
Hi,
the DateFormat used in the DateTool is supporting only a subset of ISO
8601 date/times. In particular time zones are missing, likewise one must
not use milliseconds.
I suggest using the class XsDateTimeFormat from ws-jaxme instead, which
is a thread safe instance of Format. The only
On Do, 2004-06-17 at 09:36, John Wilson wrote:
The XML-RPC spec (http://www.xml-rpc.com/spec see the last but one
bullet point) says that timezones may not be present in a date. The
generally accepted interpretation of the spec is that only the precise
subset of ISO 8601 date/times given
On Do, 2004-06-17 at 10:24, John Wilson wrote:
The example in the spec does not include milliseconds - the generally
accepted interpretation of the spec (i.e. by XML-RPC implementers) is
that they are not permitted.
If so, that leaves still more room for vendor extensions ... :-)
On Do, 2004-06-17 at 11:59, John Wilson wrote:
Apache XML-RPC (or at least Helma XML-RPC which became Apache) used to
implement null. It was removed at the request of the author of the
spec (Dave Winer). I do not believe that this should be reintroduced.
If so, how do you explain
On Do, 2004-06-17 at 12:35, John Wilson wrote:
MinML-RPC is a minimal XML-RPC implementation. This is very
interesting, but I have some pushback. There is no such thing as the
nil/ extension. If we added it, it would break at least one
implementation. Please appreciate the bigger picture.
Daniel L. Rall wrote:
+1 on committing this patch to CVS HEAD (only).
Why not better using the XsDateTimeFormat from ws-jaxme?
Daniel L. Rall wrote:
-return base64Codec.decode(cdata.getBytes());
+return base64Codec.decode((Object) cdata.getBytes());
This cast looks unnecessary. What's the thinking here?
No, it's required, because the compiler would pick the old method otherwise.
Henri Gomez wrote:
Of course, there is some excellent code in jakarta-tomcat-connecters and
the sub projet http11.
Do you have a pointer to that? (I'll not intend to use it for xml-rpc, but
privately.)
Regards,
Jochen
Hi,
I have added your patch to my private version. See my previous mail.
Jochen
Thomas Smallwood wrote:
My next question will probably result in subjective responses but I'll
ask it anyway: Is XML-RPC still a viable/reasonable solution for
client/server communication or has it been replaced by something new and
better?
I don't like it, as it is. But with some additional
14 matches
Mail list logo
