Re: transport layer abstraction

[Ryan Hoegg]

These types of changes seem to me to be good for the library, because to 
me the
XML messaging format and the transport are separate concerns.  As we look
into how these goals might be attained within the code, we should be 
careful to
identify the boundaries between the concerns appropriately.  I think one 
way we
could accomplish the transport independence is to have the XmlRpcClient and
XmlRpcServer classes send and receive messages as SAX events rather than
bytes.

More comments in response to rufio's points:

rufio wrote:

Hi
As John suggested these are changes that IMO would ease writng transport
plugins:
I think that the apache xmlrpc should be transport independant
framework, as such
- shouldn't have any http specific classes;
http classes should be moved to their own package
- shouldn't have any http specific methods;
methods like XmlRpc.setKeepAlive() should be moved to the plugin
- shouldn't assume that the transport isn't XML already, which implies
shouldn't care about encoding
I like these three.  We put all transport code into the transport layer, 
and make
encoding part of that layer.

- shouldn't assume anyting about low level connections;
e.g. while http can use connection per request-response, jabber uses
connection per resource on server side and usually 1 connection for
whole communication on client side.
I don't understand what assumptions are made now.

** those features allow people to use the framework with
other RPCs, even non-XML ones
- should allow plugin to define its own representation of message;

This sounds dangerous, and is talking about message formats.  I thought 
we were talking
about abstractint the transport?

- should allow plugin to define own SAX handlers and possibly even SAX
driver;
- client code shouldn't care about transport layer;
url is enough to guess which one to use, plugins could register much
like drivers in JDBC
I think we should tread lightly.  Most clients (so far) expect Apache 
XML-RPC to work
as the spec states, via HTTP 1.0.  IMHO anyone who wants to use 
something else
should know that it breaks the spec and therefore they will need to do 
more than a
vanilla client.

When client uses this framework with default transport, he gets XML-RPC
compilance, on the other hand architecture remains open and people may
do whatever they want.
 

This sounds like a worthwhile goal to me.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net