+1 on Dan' suggestion. As has been said many times, the wonderfulness of
xml-rpc is its tight small independence.
-Original Message-
From: Daniel Rall [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 07, 2002 8:53 PM
To: [EMAIL PROTECTED]
Subject: Re: XML-RPC client cookies?
Ryan
i Strongly concurr with that (single pass), but that means that martin has
to do it all at once very quickly, otherwise merge problems will occurr.
Perhaps a Weekend would be a good time to do it, closing the code on friday
morning, with a warning to everyone that might be working on patches, and
Hey that last piece on HTTP headers got me to thinking. The XML-RPC
spec says that an XML-RPC message is an HTTP-POST request. However when
I was looking around on the internet I remember seeing stuff about
possible other transports such as SMTP. Were these just ideas that were
being
This is something that could be done with the interceptors patch for
example:
new XmlRpcClientInterceptor() {
public void preinvoke_preflatten(String remotehost, ObjectHolder
method, ObjectHolder params, ObjectHolder user, ObjectHolder password,
ObjectHolder auth, Properties headers,
on 3/8/02 9:11 AM, Daniel Rall [EMAIL PROTECTED] wrote:
Not particularly, but won't I don't like are tons of random code
reformatting changes in the CVS diffs, especially when they're mixed
with code changes (Jon! ;-). But if everyone else is in favor of it
I'd withdraw my objects if you
I've actually begun exploring this avenue. It is
trivial to separate the wire format from the transport
aspects of the specficiation. Once you've done that
adding support, in the specification, for a new
transport is just a matter of describing how the
transport transfers messages in the XML-RPC
Ryan Hoegg [EMAIL PROTECTED] writes:
Am I over-rating the complexity of a Tomcat setup?
Yes. What I'm suggesting is little more than replacing one web server
with another. If you're worried about the size of Tomcat, Jon Stevens
has a stripped down version of Catalina (with no JSP) in Scarab
I'm goning to skip this one (though I'm not against someone else
sprucing that up and merging it in). What's actually needed is some
code normalization between client, client lite, and server header
generation.
Ryan Hoegg [EMAIL PROTECTED] writes:
Hi all,
Not too sure if this is something
Ryan Hoegg [EMAIL PROTECTED] writes:
Hi Daniel, and everyone,
In my research into my cookie issue, I found some interesting ideas.
What would you all think about using the Jakarta Commons HTTP Client
instead of java.net.URLConnection?
That wouldn't address the server header generation but
