I think we're fine.
Their new version has added code that will raise an exception if any
non-base64 data is present in the input, so I think the check in
discardWhitespace was just extraneous --- this is a better way to do
it, and still RFC compliant ...
Monday, March 3, 2003, at 08:21 AM,
I have an application that is accessed via xml-rpc by a Flash client
(I am developing the back-end, while they take care of the client and
ui). I'm not sure exactly what version of Flash they are using, but
AFAIK, they haven't had any significant problems with the xmlrpc part.
I believe the
Hi Ryan,
I would get my additional changes in (or at least bring them to
Tim's attention), as they are a definite step forward, in terms of both
RFC compliance and efficiency (Danny's comment about trailing CR/LF's
not withstanding) ...
On Monday, February 3, 2003, at 10:33 PM, Ryan Hoe
On Monday, February 3, 2003, at 08:37 PM, Ryan Hoegg wrote:
I've seen these fly by as you have been updating the Bug. I imagine
most of these are Good Things, but I think the Codec people will have
concerns about silently ignoring things the RFC encourages us to
complain about. You think we
On Monday, February 3, 2003, at 07:52 PM, Ryan Hoegg wrote:
Looks like the appropriate people have been made aware.
Thanks for checking that one out, Martin!
np, but you might want to check out my most recent patches on bug 9931.
These added:
a final newline to encoded data (which seems to
I just had a look at the HttpClient version. I can't see much
difference from the "base" Base64 code (the one that subsequently got
copied into various jakarta projects), apart from some reformatting.
The httpclient version still has the whitespace and non-Base64
character issues ...
On M
On Thursday, January 30, 2003, at 09:47 PM, Ryan Hoegg wrote:
Daniel Rall wrote:
p.s. Did the base-64 fixes make it into both 1.2 branch _and_ HEAD?
Not yet. I think the issue is basically closed except for some
uncertainty on performance with large inputs.
There's a new comment added to
Hi All,
I've been chatting to Ryan offlist, looking for ways to help out,
and he's suggested that I look at the functional requirements for
different xml-rpc use cases, to help in sub packaging and creating
different jars.
That said, I am currently trying to sort out the client use cases
I just looked on the website, and there are no commits for 30 days,
apparently :-)
Is there any news on progress for the next release?
If there's anything I can do to help, let me know ...
Enhancement request.
I guess you guys are still deep in the code, but here's an enhancement
request.
A method on XmlRpcClient (and I guess SecureXmlRpcClient), with a
method signature as follows:
public Object execute(String method, byte[] request)
and/or
public Object execute(String method
10 matches
Mail list logo
