You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/12/19 10:27:13 UTC
XMLRPC block
What would people think of a Phoenix service/block that used XMLRPC from
our sister site?
http://xml.apache.org/xmlrpc/
We could have a factory that publishes a service or interface over HTTP
and a binding on the client side that turns the same interface calls
into RPC calls. The example code seems quite cumbersome, but I have a
feeling that if the interface only uses standard class types, we could
have hide the XMLRPC implementation behind java interfaces and use
reflection at runtime on both sides to build the method lists. XMLRPC
also forces two exception to be handled on the client side
(XmlRpcException and IOException), but I think they could be rethrown as
a custom derivative of RuntimeException (like Glue does). The
difference with this is that we can place the XMLRPC jars in CVS (they
are Apache jars).
Perhaps an important factor is need. Do we really need this if we are
going to have native RMI solution along the same lines. At least for
the Soapification service there is the realistic possibility of non-java
clients.
Opinions?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XMLRPC block
Posted by Peter Donald <pe...@apache.org>.
On Wed, 19 Dec 2001 22:56, Ulrich Mayring wrote:
> Paul Hammant wrote:
> > What would people think of a Phoenix service/block that used XMLRPC from
> > our sister site?
> >
> > http://xml.apache.org/xmlrpc/
> >
> > We could have a factory that publishes a service or interface over HTTP
> > and a binding on the client side that turns the same interface calls
> > into RPC calls.
>
> The first part (publishing services over HTTP) seems very interesting, I
> think there is more need for that than for XMLRPC.
Feel free to whack together something like that then ! ;)
--
Cheers,
Pete
----------------------------------
Ancient Go proverb: "Only amateurs
try to come up with 'fancy' moves"
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XMLRPC block
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Hammant wrote:
>
> What would people think of a Phoenix service/block that used XMLRPC from
> our sister site?
>
> http://xml.apache.org/xmlrpc/
>
> We could have a factory that publishes a service or interface over HTTP
> and a binding on the client side that turns the same interface calls
> into RPC calls.
The first part (publishing services over HTTP) seems very interesting, I
think there is more need for that than for XMLRPC.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XMLRPC block
Posted by Peter Donald <pe...@apache.org>.
On Wed, 19 Dec 2001 20:27, Paul Hammant wrote:
> What would people think of a Phoenix service/block that used XMLRPC from
> our sister site?
>
> http://xml.apache.org/xmlrpc/
>
> We could have a factory that publishes a service or interface over HTTP
> and a binding on the client side that turns the same interface calls
> into RPC calls. The example code seems quite cumbersome, but I have a
> feeling that if the interface only uses standard class types, we could
> have hide the XMLRPC implementation behind java interfaces and use
> reflection at runtime on both sides to build the method lists. XMLRPC
> also forces two exception to be handled on the client side
> (XmlRpcException and IOException), but I think they could be rethrown as
> a custom derivative of RuntimeException (like Glue does). The
> difference with this is that we can place the XMLRPC jars in CVS (they
> are Apache jars).
>
> Perhaps an important factor is need. Do we really need this if we are
> going to have native RMI solution along the same lines. At least for
> the Soapification service there is the realistic possibility of non-java
> clients.
>
> Opinions?
go for it. The native version is not going to be avaialable for a bit.
--
Cheers,
Pete
When a stupid man is doing something he's ashamed of, he always
declares that it is his duty.
George Bernard Shaw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>