www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - status of mango.xml.rpc

reply Alberto <reda zioale.it> writes:
What is the status of mango.xml.rpc.Server?
I need it for my application, will be great if at least the developers
release the syntax (I saw that it has changed from mango v2.1 for the
rpc.Client),so I can start to work on my project..
And it's planned to add base64 and date types in mango.xml.rpc.Client?
now they are missing..
I need base64, I have added it to rpc.Client using ubyte[] as basic type
(like some rpc client/server in java). Basically I did a sort of
copy/paste of string code but using ubyte[] instead of char[], very
spartan but it works.
For sure your version will be better.
Feb 17 2007
parent reply John Demme <me teqdruid.com> writes:
Alberto wrote:

 What is the status of mango.xml.rpc.Server?
 I need it for my application, will be great if at least the developers
 release the syntax (I saw that it has changed from mango v2.1 for the
 rpc.Client),so I can start to work on my project..
 And it's planned to add base64 and date types in mango.xml.rpc.Client?
 now they are missing..
 I need base64, I have added it to rpc.Client using ubyte[] as basic type
 (like some rpc client/server in java). Basically I did a sort of
 copy/paste of string code but using ubyte[] instead of char[], very
 spartan but it works.
 For sure your version will be better.

I've made a start on the server portion, but I've got some work yet on it. Expect an alpha in about a week- hopefully less. As for base64- the only reason I don't have base64 support yet is because Tango doesn't have a base64 encoder. I don't have any plans on adding it until it's in Tango, so I'd appreciate it if someone could talk to the Tango guys about it and do it. As for date support... It's just lower priority than the server stuff, so I've put it off until then. It'd be nice if Tango had a iso8601 encoder/parser to make my life easier, but I don't have a big problem with implementing it in the xml-rpc package. I'm glad someone is using a looking around my code. It's obviously alpha right now, but whadda ya think? I'm a bit concerned that the SAX-style I/O is a bit awkard, but it avoids creating lots of intermediate object trees, so it should perform pretty well. I was also pretty impressed with D's IFTI support and templates. It's been about a year since I've really used the template stuff, and the new stuff made some of my work really easy. I'm really happy with the way the client templates came out. I'm planning on having the server module also use a sax-style API, but I can't release the API for it b/c I haven't written it yet. I don't write the API in advance- I prefer to write it as I write the module since writing the module typically changes what I thought the API should look like. -- ~John Demme me teqdruid.com http://www.teqdruid.com/
Feb 17 2007
parent reply Alberto <reda zioale.it> writes:
 I've made a start on the server portion, but I've got some work yet on it. 
 Expect an alpha in about a week- hopefully less.

 I'm planning on having the server module also use a sax-style API, but I
 can't release the API for it b/c I haven't written it yet.

months...)
 I'm glad someone is using a looking around my code.  It's obviously alpha
 right now, but whadda ya think?  

have some doubts about using an XmlRpcResponseHandler for every rpc call. I should implement all those classes just to get some simple return value (for example an int value). I think that would be better to use another way (2 ways are better than 1) to get the results. The choice will depend on what the user must do.
Feb 18 2007
parent Alberto <reda zioale.it> writes:
I can do just an example (from apache xmlrpc)

execute return an object, so I can do something like:

XmlRpcClient client = new XmlRpcClient("....");
Object[] params = new Object[]{new Integer(2), new Integer(3)};
Integer result = (Integer) client.execute("Calculator.add", params);

I think that for many rpc calls this is very useful..
Feb 18 2007