On Thu, 5 Jul 2001, Jason van Zyl wrote:
> [ ]Craig McClanahan
Just getting back from vacation, I've read this thread and tend to agree
with the general consensus that it belongs more on the xml.apache.org side
of the house, for several reasons:
* This particular implementation is written in Java, but the spec itself
<http://www.xmlrpc.org> has been implemented in many languages.
* Having a Java implementation first is cool and all, but we should be
able and willing to host non-Java implementations as well -- and Jakarta
is not the right place for that. That's what xml.apache.org is about.
* In the pure-Java world, I think an "RPC over XML" solution that
implements the JAX-RPC API (JSR 101) would make sense as a Jakarta
project (assuming the issues that Apache has with the Java Community
Process can be worked out :-). There, it's not an issue of supporting
the same spec in multiple languages -- it's an issue of supporting a
Java-specific API with a robust, high-performance implementation.
Officially, this counts as
[-0] Craig McClanahan
Craig
PS: By the way (to Sam and others), I don't consider the use of a
specialized XML parser (or an embedded HTTP server, for that matter) to be
a fatal design flaw. Performance should have a strong influence on that
sort of choice, and if it runs faster with specialized tools instead of
Xerces and Tomcat for this particular application, more power to 'em.
On the other hand, if they cannot *significantly* outperform general
purpose tools, then it's pretty much wasted effort to spend the developer
time necessary to maintain those components. Time will tell -- therefore,
hosting this initially as a separate top-level project makes the most
sense to me. But I'd hope that the XML-RPC developers recognize that this
is an important tradeoff.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
