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.

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/

> 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.
wow :)

> 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.
It's not a problem if the alpha will be released in few weeks (I thought
 months...)

> I'm glad someone is using a looking around my code.  It's obviously alpha right now, but whadda ya think?
I have tried the client and it looks good, very simple to use, but I
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.

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..