on Thu, 17 Jul 2003 12:37:36 -0400 Ryan Hoegg <[EMAIL PROTECTED]> wrote:
> <cut> 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. Great idea, additionally if SAX2 were used, plugins that uses XML could simply provide XMLFilter implementation. > <cut> > >- 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. They aren't, but I think thet might appear in abstracting server side. > > >** 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? oops, you're right. I was thinking too abstract :) > > >- 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. Exactly, client has to explictly say that he wants "jabber-rpc://some/service" or else he gets default transport. > 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. On the other hand client may take the URL from another source (like some repository) and doesn't care about the transport layer
