You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Jim Redman <ji...@ergotech.com> on 2002/11/04 00:29:00 UTC
XmlRpcClient Interface
I only vaguely remember the discussion of adding an interface for the
client. Can someone provide a quick synopsis and the status?
It just became relevent to me because I have a need for a CLDC client.
kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just about)
CLDC compliant, if I can easily convert the XmlRpcClient to CLDC I may
have a good solution. If I'm going to do this, I might as well make it
compliant with the forthcoming interface.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Sounds like I'm not the only outsider interested in this code! How
> >about a short-lived CLIENT_REFACTORING branch in CVS? We could give
> >Ryan commit access, and you guys could proceed with the development
> >from here on out in ASF CVS. Everyone would be free to comment, and
> >we can merge into the mainline when you think things are ready. I'd
> >be happy to help with any CVS/branching/merging issues. Thoughts?
> >
> Well we are having a bit of a feature creep here. It is no longer
> just CLIENT_REFACTORING as we are looking at abstracting the transport
> layer for the XmlRpcServer code as well. I would be interested in
> having this code up in CVS somewhere, although I've never worked with
> CVS branches before.
Working with branches mostly involves appending -rBRANCH_NAME to your
cvs checkout and update commands. Eventually, you learn how to use
update -j to merge branches together.
> Another thing I'm not sure about is design documentation. Sometimes
> it helps me to draw up larger refactorings like this one in quasi-UML
> so I can see the bigger picture. If I do this, do I store the
> .VSD/.PNGs in CVS somewhere? Where? It would be nice to have them as
> a resource when we are talking over some of the design decisions we
> are making.
Yes, they should live in the repository, possibly under xdocs/
(assuming they have associated content).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Sounds like I'm not the only outsider interested in this code! How
> >about a short-lived CLIENT_REFACTORING branch in CVS? We could give
> >Ryan commit access, and you guys could proceed with the development
> >from here on out in ASF CVS. Everyone would be free to comment, and
> >we can merge into the mainline when you think things are ready. I'd
> >be happy to help with any CVS/branching/merging issues. Thoughts?
> >
> Well we are having a bit of a feature creep here. It is no longer
> just CLIENT_REFACTORING as we are looking at abstracting the transport
> layer for the XmlRpcServer code as well. I would be interested in
> having this code up in CVS somewhere, although I've never worked with
> CVS branches before.
Working with branches mostly involves appending -rBRANCH_NAME to your
cvs checkout and update commands. Eventually, you learn how to use
update -j to merge branches together.
> Another thing I'm not sure about is design documentation. Sometimes
> it helps me to draw up larger refactorings like this one in quasi-UML
> so I can see the bigger picture. If I do this, do I store the
> .VSD/.PNGs in CVS somewhere? Where? It would be nice to have them as
> a resource when we are talking over some of the design decisions we
> are making.
Yes, they should live in the repository, possibly under xdocs/
(assuming they have associated content).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Sounds like I'm not the only outsider interested in this code! How
>about a short-lived CLIENT_REFACTORING branch in CVS? We could give
>Ryan commit access, and you guys could proceed with the development
>from here on out in ASF CVS. Everyone would be free to comment, and
>we can merge into the mainline when you think things are ready. I'd
>be happy to help with any CVS/branching/merging issues. Thoughts?
>
Well we are having a bit of a feature creep here. It is no longer just
CLIENT_REFACTORING as we are looking at abstracting the transport layer
for the XmlRpcServer code as well. I would be interested in having this
code up in CVS somewhere, although I've never worked with CVS branches
before.
Another thing I'm not sure about is design documentation. Sometimes it
helps me to draw up larger refactorings like this one in quasi-UML so I
can see the bigger picture. If I do this, do I store the .VSD/.PNGs in
CVS somewhere? Where? It would be nice to have them as a resource when
we are talking over some of the design decisions we are making.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
>
>
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Sounds like I'm not the only outsider interested in this code! How
>about a short-lived CLIENT_REFACTORING branch in CVS? We could give
>Ryan commit access, and you guys could proceed with the development
>from here on out in ASF CVS. Everyone would be free to comment, and
>we can merge into the mainline when you think things are ready. I'd
>be happy to help with any CVS/branching/merging issues. Thoughts?
>
Well we are having a bit of a feature creep here. It is no longer just
CLIENT_REFACTORING as we are looking at abstracting the transport layer
for the XmlRpcServer code as well. I would be interested in having this
code up in CVS somewhere, although I've never worked with CVS branches
before.
Another thing I'm not sure about is design documentation. Sometimes it
helps me to draw up larger refactorings like this one in quasi-UML so I
can see the bigger picture. If I do this, do I store the .VSD/.PNGs in
CVS somewhere? Where? It would be nice to have them as a resource when
we are talking over some of the design decisions we are making.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
>
>
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > I have the CLDC code, but didn't find the interface. Is it hidden in
> > CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> > recollection is that there are plans for this that will modify it
> > significantly.
>
> Ryan and I are sharing code via private email at the moment.
Sounds like I'm not the only outsider interested in this code! How
about a short-lived CLIENT_REFACTORING branch in CVS? We could give
Ryan commit access, and you guys could proceed with the development
from here on out in ASF CVS. Everyone would be free to comment, and
we can merge into the mainline when you think things are ready. I'd
be happy to help with any CVS/branching/merging issues. Thoughts?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > I have the CLDC code, but didn't find the interface. Is it hidden in
> > CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> > recollection is that there are plans for this that will modify it
> > significantly.
>
> Ryan and I are sharing code via private email at the moment.
Sounds like I'm not the only outsider interested in this code! How
about a short-lived CLIENT_REFACTORING branch in CVS? We could give
Ryan commit access, and you guys could proceed with the development
from here on out in ASF CVS. Everyone would be free to comment, and
we can merge into the mainline when you think things are ready. I'd
be happy to help with any CVS/branching/merging issues. Thoughts?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Andrew Evers <ae...@redwood.nl>.
> I have the CLDC code, but didn't find the interface. Is it hidden in
> CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> recollection is that there are plans for this that will modify it
> significantly.
Ryan and I are sharing code via private email at the moment.
> This is the gist of the modifications. I removed the superclass
> (XmlRpcClient) and copied a couple of methods across and removed the
> superclass of LiteWorker (Worker) and copied some methods. I think
> that I also trashed the Async code. There are minor changes to
> XmlRpc.java (removing "properties"), other than that, you need
> Base64.java, ServerInputStream.java and XmlRpcException.java which
> compile unchanged. I think that there also some supporting classes
> that we had already created (StringTokenizer?), maybe others.
> References to URL and associated exceptions have been removed, if we
> need these to match a new interface (likely) we will need to create
> substitutes.
>
> If anyone else has an immediate interest in this code, let me know.
> I'll be testing over this week, the goal is to get it on the
> iPaq/Jeode.
I wouldn't mind seeing a copy (either a unidiff against HEAD or a
..jar of .java files). I can tell you fairly quickly how easy it would
be to integrate this.
I've not done any CLDC programming myself. What are the constraints we
are looking at? How important is code size, and the number of classes?
are there particular classes that we are using that aren't available
under CLDC?
>>> I only vaguely remember the discussion of adding an interface for
>>> the client. Can someone provide a quick synopsis and the status?
Well, the idea is to split the XML-RPC and HTTP processing. The
XML-RPC processing on the client side will be done in a similar
manner to the server side code in HEAD. There are three new classes:
XmlRpcClientRequestProcessor, XmlRpcClientResponseProcessor and
XmlRpcClientWorker. These contain the request/response/worker
code that was common to XmlRpcClient and XmlRpcClientLite. Look how
this is done on the server for an idea.
The HTTP processing is handled by having XmlRpcClient make a call
to an XmlRpcTransport instance:
public InputStream sendXmlRpc(byte [] request)
throws IOException, XmlRpcClientException;
Creation of these instances is via a factory method in XmlRpcClient:
protected XmlRpcTransport createTransport()
The default is to create a new transport (== new connection) for
each XML-RPC. It is possible to set things up to do XML-RPC on
a persistent connection.
>>> It just became relevent to me because I have a need for a CLDC
>>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>>> (just about) CLDC compliant, if I can easily convert the
>>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>>> this, I might as well make it compliant with the forthcoming
>>> interface.
The solution may be to create an org.apache.xmlrpc.cldc.CLDCXmlRpcClient
class that depends on the MinML package, and a subset of the core
org.apache.xmlrpc package:
XmlRpc
XmlRpcException
XmlRpcClientRequestProcessor (see above)
XmlRpcClientResponseProcessor (see above)
HttpClient (I've factored this out of XmlRpcClientLite).
Base64
ServerInputStream
This would have no main(), no asynchronous handling, no workers or
worker stack, etc. But, it would be _very_ small.
Andrew.
Re: XmlRpcClient Interface
Posted by Andrew Evers <ae...@redwood.nl>.
> I have the CLDC code, but didn't find the interface. Is it hidden in
> CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> recollection is that there are plans for this that will modify it
> significantly.
Ryan and I are sharing code via private email at the moment.
> This is the gist of the modifications. I removed the superclass
> (XmlRpcClient) and copied a couple of methods across and removed the
> superclass of LiteWorker (Worker) and copied some methods. I think
> that I also trashed the Async code. There are minor changes to
> XmlRpc.java (removing "properties"), other than that, you need
> Base64.java, ServerInputStream.java and XmlRpcException.java which
> compile unchanged. I think that there also some supporting classes
> that we had already created (StringTokenizer?), maybe others.
> References to URL and associated exceptions have been removed, if we
> need these to match a new interface (likely) we will need to create
> substitutes.
>
> If anyone else has an immediate interest in this code, let me know.
> I'll be testing over this week, the goal is to get it on the
> iPaq/Jeode.
I wouldn't mind seeing a copy (either a unidiff against HEAD or a
..jar of .java files). I can tell you fairly quickly how easy it would
be to integrate this.
I've not done any CLDC programming myself. What are the constraints we
are looking at? How important is code size, and the number of classes?
are there particular classes that we are using that aren't available
under CLDC?
>>> I only vaguely remember the discussion of adding an interface for
>>> the client. Can someone provide a quick synopsis and the status?
Well, the idea is to split the XML-RPC and HTTP processing. The
XML-RPC processing on the client side will be done in a similar
manner to the server side code in HEAD. There are three new classes:
XmlRpcClientRequestProcessor, XmlRpcClientResponseProcessor and
XmlRpcClientWorker. These contain the request/response/worker
code that was common to XmlRpcClient and XmlRpcClientLite. Look how
this is done on the server for an idea.
The HTTP processing is handled by having XmlRpcClient make a call
to an XmlRpcTransport instance:
public InputStream sendXmlRpc(byte [] request)
throws IOException, XmlRpcClientException;
Creation of these instances is via a factory method in XmlRpcClient:
protected XmlRpcTransport createTransport()
The default is to create a new transport (== new connection) for
each XML-RPC. It is possible to set things up to do XML-RPC on
a persistent connection.
>>> It just became relevent to me because I have a need for a CLDC
>>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>>> (just about) CLDC compliant, if I can easily convert the
>>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>>> this, I might as well make it compliant with the forthcoming
>>> interface.
The solution may be to create an org.apache.xmlrpc.cldc.CLDCXmlRpcClient
class that depends on the MinML package, and a subset of the core
org.apache.xmlrpc package:
XmlRpc
XmlRpcException
XmlRpcClientRequestProcessor (see above)
XmlRpcClientResponseProcessor (see above)
HttpClient (I've factored this out of XmlRpcClientLite).
Base64
ServerInputStream
This would have no main(), no asynchronous handling, no workers or
worker stack, etc. But, it would be _very_ small.
Andrew.
Re: XmlRpcClient Interface
Posted by Jim Redman <ji...@ergotech.com>.
I have the CLDC code, but didn't find the interface. Is it hidden in
CVS or elsewhere? Also I modified the XmlRpcClientLite, my
recollection is that there are plans for this that will modify it
significantly.
Kudos to all the committers of this project, the changes were fairly
simple. This is due to a number things, a desire to keep the
architecture fairly simple, maintaining JDK 1.1 compliance and using
MinML. Special thanks to John for this last.
This is the gist of the modifications. I removed the superclass
(XmlRpcClient) and copied a couple of methods across and removed the
superclass of LiteWorker (Worker) and copied some methods. I think
that I also trashed the Async code. There are minor changes to
XmlRpc.java (removing "properties"), other than that, you need
Base64.java, ServerInputStream.java and XmlRpcException.java which
compile unchanged. I think that there also some supporting classes
that we had already created (StringTokenizer?), maybe others.
References to URL and associated exceptions have been removed, if we
need these to match a new interface (likely) we will need to create
substitutes.
If anyone else has an immediate interest in this code, let me know.
I'll be testing over this week, the goal is to get it on the iPaq/Jeode.
Jim
On 2002.11.03 17:30 Ryan Hoegg wrote:
> Jim,
>
> Sounds great! I think the status now is that we are keeping the
> XmlRpcClient class but pulling out the salient bits into more focused
> classes. The XmlRpcClient class will depend only on interfaces, and
> implementations for those interfaces will be distributed in separate
> packages to facilitate building JARs that are tailored to specific
> users. This is all still pre-alpha of course, and we weclome further
> discussion.
>
> Your's looks like a great use case to help us with the design
> direction here. If you search the archives for the "HttpClient
> Integration" thread you can read a lot of the recent progress in this
> area, with the bulk of the tangible code coming from Andrew Evers.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
> Jim Redman wrote:
>
>> I only vaguely remember the discussion of adding an interface for
>> the client. Can someone provide a quick synopsis and the status?
>>
>> It just became relevent to me because I have a need for a CLDC
>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>> (just about) CLDC compliant, if I can easily convert the
>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>> this, I might as well make it compliant with the forthcoming
>> interface.
>>
>> Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: XmlRpcClient Interface
Posted by Jim Redman <ji...@ergotech.com>.
I have the CLDC code, but didn't find the interface. Is it hidden in
CVS or elsewhere? Also I modified the XmlRpcClientLite, my
recollection is that there are plans for this that will modify it
significantly.
Kudos to all the committers of this project, the changes were fairly
simple. This is due to a number things, a desire to keep the
architecture fairly simple, maintaining JDK 1.1 compliance and using
MinML. Special thanks to John for this last.
This is the gist of the modifications. I removed the superclass
(XmlRpcClient) and copied a couple of methods across and removed the
superclass of LiteWorker (Worker) and copied some methods. I think
that I also trashed the Async code. There are minor changes to
XmlRpc.java (removing "properties"), other than that, you need
Base64.java, ServerInputStream.java and XmlRpcException.java which
compile unchanged. I think that there also some supporting classes
that we had already created (StringTokenizer?), maybe others.
References to URL and associated exceptions have been removed, if we
need these to match a new interface (likely) we will need to create
substitutes.
If anyone else has an immediate interest in this code, let me know.
I'll be testing over this week, the goal is to get it on the iPaq/Jeode.
Jim
On 2002.11.03 17:30 Ryan Hoegg wrote:
> Jim,
>
> Sounds great! I think the status now is that we are keeping the
> XmlRpcClient class but pulling out the salient bits into more focused
> classes. The XmlRpcClient class will depend only on interfaces, and
> implementations for those interfaces will be distributed in separate
> packages to facilitate building JARs that are tailored to specific
> users. This is all still pre-alpha of course, and we weclome further
> discussion.
>
> Your's looks like a great use case to help us with the design
> direction here. If you search the archives for the "HttpClient
> Integration" thread you can read a lot of the recent progress in this
> area, with the bulk of the tangible code coming from Andrew Evers.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
> Jim Redman wrote:
>
>> I only vaguely remember the discussion of adding an interface for
>> the client. Can someone provide a quick synopsis and the status?
>>
>> It just became relevent to me because I have a need for a CLDC
>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>> (just about) CLDC compliant, if I can easily convert the
>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>> this, I might as well make it compliant with the forthcoming
>> interface.
>>
>> Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Jim,
Sounds great! I think the status now is that we are keeping the
XmlRpcClient class but pulling out the salient bits into more focused
classes. The XmlRpcClient class will depend only on interfaces, and
implementations for those interfaces will be distributed in separate
packages to facilitate building JARs that are tailored to specific
users. This is all still pre-alpha of course, and we weclome further
discussion.
Your's looks like a great use case to help us with the design direction
here. If you search the archives for the "HttpClient Integration"
thread you can read a lot of the recent progress in this area, with the
bulk of the tangible code coming from Andrew Evers.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jim Redman wrote:
> I only vaguely remember the discussion of adding an interface for the
> client. Can someone provide a quick synopsis and the status?
>
> It just became relevent to me because I have a need for a CLDC
> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just
> about) CLDC compliant, if I can easily convert the XmlRpcClient to
> CLDC I may have a good solution. If I'm going to do this, I might as
> well make it compliant with the forthcoming interface.
>
> Jim
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Jim,
Sounds great! I think the status now is that we are keeping the
XmlRpcClient class but pulling out the salient bits into more focused
classes. The XmlRpcClient class will depend only on interfaces, and
implementations for those interfaces will be distributed in separate
packages to facilitate building JARs that are tailored to specific
users. This is all still pre-alpha of course, and we weclome further
discussion.
Your's looks like a great use case to help us with the design direction
here. If you search the archives for the "HttpClient Integration"
thread you can read a lot of the recent progress in this area, with the
bulk of the tangible code coming from Andrew Evers.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jim Redman wrote:
> I only vaguely remember the discussion of adding an interface for the
> client. Can someone provide a quick synopsis and the status?
>
> It just became relevent to me because I have a need for a CLDC
> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just
> about) CLDC compliant, if I can easily convert the XmlRpcClient to
> CLDC I may have a good solution. If I'm going to do this, I might as
> well make it compliant with the forthcoming interface.
>
> Jim