Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[aum]

Hi,

I've just switched from monolithic amule to amuled/amuleweb, and am greatly appreciating the ability to leave amuled running and doing its thing 24/7 on my headless box.

However, while amuleweb is pretty good, and a nice attempt at providing a similar ui to the monolithic, I see room for some more flexibility.

What do people think of implementing a client with an xmlrpc listener at its front end, and talking to amuled at its back end?

A supported xmlrpc interface to amuled - either built-in to amuled, or implemented separately as a client - would open up development opportunities to a huge range of people, given that xmlrpc makes all language-related issues go away, and simplifies the task of interfacing.

Thoughts?

Cheers
aum

[lfroen]

As I already answered you in other thread: we're not going to have SOAP any time soon. Do you know that amuleweb have PHP interpreter (limited one, but anyway) built-in ?
If this is not flexible enough - I have no idea what are you talking about.

[Kry]

He's talking about a man-in-the-middle client translating our ECv2 protocol to the xml-rpc, lfroen. I see nothing bad on it.

[lfroen]

man-in-the-middle client translating our ECv2 protocol to the xml-rpc

Nothing bad, and the man is definitly welcome to write a client translating EC to whatever he thinks is right/good/useful.
BUT: I never met people that like to read xml, so output is gonna to fed to some program. Now it's time when I fail to see what is it good for (except for execsizing coders skills).
Whoever sees things differently may educate me.

[Kry]

You don't have what is it good for. It's his choice.

[aum]

Originally posted by lfroen

man-in-the-middle client translating our ECv2 protocol to the xml-rpc

Nothing bad, and the man is definitly welcome to write a client translating EC to whatever he thinks is right/good/useful.
BUT: I never met people that like to read xml, so output is gonna to fed to some program. Now it's time when I fail to see what is it good for (except for execsizing coders skills).
Whoever sees things differently may educate me.

Every time I mention XML-RPC, people often comment that 'all that weird angle-bracket syntax will put people off'. Therein is one of the myths of XML-RPC.

True - requests and responses are XML-encoded and sent via an HTTP POST request/response cycle.

However, XML-RPC is implemented as a high-level library in almost all of the common languages - C, C++, Python, Ruby, Java, OCaml, Perl etc, and the respective APIs for those languages don't expose the client programmer to a single angle-bracket.

The beauty of XML-RPC is that it wraps objects in a language-agnostic way, permitting the implementation of clients in any language.

Python's XML-RPC API is especially elegant - in a large part, the wrapped objects look and feel just like native Python objects. And in Java, and C++, it's almost as luxurious. In C, there's a bit of red tape to go through, but nothing that doesn't come up in routine C programming anyway.

IMHO, perhaps the best place to implement an XML-RPC interface might be within amuleweb, since amuleweb already implements HTTP POST, the underlying transport for XML-RPC.

Cheers
aum

[lfroen]

aum: you did not answered the question: "In given design of amule/amuled/amuleweb/EC, what is xml-rpc can be used to ?".
I know how it works, i just can't see what to do with it. Original discussion was about replacing EC with xmp-rpc cycle. Whether this good idea or not, the answer to "what is it for is  for" is clear. But now we talking about translating EC to xml and then feding it to .... where ?

Actually when I thing about it, you can have this functionality by providing to php engine of amuleweb appropriate template. Just do

Code: [Select]

echo '', $filename, ''or similar and you will have your xml responses.