Apache XMLRPC 1.0 Released

jvanzyl writes "The Apache XMLRPC team is pleased to announce the 1.0 release! Apache XML-RPC is a Java implementation of XML-RPC, a popular protocol that uses XML over HTTP to implement remote procedure calls. Apache XML-RPC was previously known as Helma XML-RPC. If you have code using the Helma library, all you should have to do is change the import statements in your code from helma.xmlrpc.* to org.apache.xmlrpc.*."

Comments

Now...

[ShadeEagle]

It's gonna be sweet to see what people are gonna be churning out with THIS...

unless it ends up being yet ANOTHER way to make bloated web pages that you NEED broadband to download.

It's sad to see that some websites just don't get the hint and not use ALL the bells-and-whistles to make their site more interactive/fun/easy to navigate/etc.

I find that you can STILL do a LOT with text, tables, and pictures. Or maybe a 2-piece frameset. However, it's been my experience that whenever a new "toy" has been thrown into the mix, it ends up being overused until I(and most likely others) end up filtering out the offending code and replacing it with 'better'* code.

* - 'Better' meaning cleaner/less confusing/consumes less resources/etc.

Perhaps I'm just nostalgic for the days of Mosaic for Windows 3.1.

Or perhaps I'm just becoming a stickler for well-done HTML :-p

I'm done venting about my opinions on web design and web technologies... comment as you see fit.

Re:Now...

[danielrall]

Or perhaps you don't have a clue what XML-RPC is? Try the spec for clarification.

Re:Now...

[ShadeEagle]

Oh, I'm not ENTIRELY schooled on the subject, but I DO know that it does have a lot of potential use in the 'general use' category.

Re:Now...

[sjehay]

I think you've made a mistake here and haven't quite understood what XML-RPC is for... it's not designed and can't be used for general bells-and-whistles on websites, but instead in its simplest form is a way for two applications to communicate with each other by invoking remote methods, passing parameters, getting results back etc, as any RPC protocol is. It shouldn't affect web design at all...

Re:Now...

[Anonymous Coward]

dude, you have no idea.

Re:Now...

[Anonymous Coward]

Try learning what rpc is before commenting on it.
xmlrpc has nothing to do with web design.
Get a clue at some stage.

Soap

[Karma 50]

Is this compatible with SOAP? I thought they were working towards that but there's nothing in the announcement about it ...

Re:Soap

[Oily Tuna]

Were you thinking of Axis?. It's still work in progress, because SOAP is too

Whats the deal

[MadCamel]

What's the deal with XML? It's just a markup language, big deal. Why impliment an RPC system based on XML? You want to see how bloated you can make it or what? I mean, be sensible, RPC can be implimented in much simpler ways without losing any 'features'. Score one more to the bloat god.

Re:Whats the deal

[thedarkstorm]

I don't think you truly see the potential here. This would allow you to do language independant and platform independant (exclude OS's that don't support TCP/IP) methodology of doing RPC. Suppose for example you have a VB server (cough cough) application on Windows and a Kylix app on Linux and you need to perform RPC. This would be a VERY simple way of doing it without the bloat of SOAP.

Re:Whats the deal

[Anonymous Coward]

I think _YOU_ missed the point of what above said. The _SAME_ functionality can be achieved with a better support protocol than XML _AND_ yes the platform independence and all that _CAN_ be preserverd.

thank you

Re:Whats the deal

[Lord of Caustic Soda]

This is how much I give a damn about the XMLRPC thing:

Yeah, that much...... on the other hand, I pray regularly that Apache 2.0 gets to official release, and if sacrificing a newborn baby helps, then I'd do it!

Re:Whats the deal

[the eric conspiracy]

Yeah, I just finished doing something like this. I needed an way of managing accounts to an IMAP mail server from a Java based web site - on the mail server I wanted to use a Perl IMAP module. XML-RPC to the rescue. A Java client and a Perl server - done.

Re:Whats the deal

[FerrisOxideTheYounge]

I've just had the experience of dealing with an oddball proprietry RPC protocol in Delphi. Things were going pear-shaped quickly so we switched to XML-RPC. What a hoot! It doesn't do everything I want it to, but it works faster than SOAP or the proprietry protocol ever would. It also means that now I don't feel so stuck in Win32 land - I might have to write a Delphi server at present, but now I can talk to the world outside. When (if) we port to Kylix I won't have to change RPC protocols. I'm happy.

Potential use?

[digitalmonkey2k1]

Im new to this world of XML, but as I see so far with this we would be able to cut out the extras in an rpc that we wouldnt need. Rather than creating code bloat we SHOULD be able to cut out features that we don't need, not only to lower code size for ourselves buit to also increase security of not having unneeded features that may or may not be able to be turned on in th event of a hole in system protection... But as I said, Newbe to XML, and rather vague in RPC. So My thoughts on this could be way out in east bumble. Please correct any errors for me people, I need to learn somehow!

Re:Potential use?

[Anonymous Coward]

XML make suck up bandwidth needlessly, but it doesn't contribute to source code bloat or lesser security. In fact, it should reduce code bloat and better security.
</P>
<P>
Fast, simple, well-tested XML parsers can be used
to parse incoming requests and marshall outgoing requests. So, XML <B>reduces</B> code bloat
and <B>heightens</B> security. Not that XML is a necessity for this, but all-in-all, being a uniform standard, it helps.</P>

interesting

[thedarkstorm]

I've been following this for some time since I accidentaly bought the O'Reilly book by mistake (was actually looking for a book on SOAP) when it was onsale. The 'pusher' behind this is MicroSoft. What's interesting is the big pusher that used to be behind SOAP was MicroSoft as well. Correct me if I'm wrong, but XML-RPC is a much ligher-weight XML competitor to SOAP-RPC. Yes, SOAP does much more than RPC, but that was the original intention behind it. Could MS be pushing XML-RPC because it's lost the majority of control of SOAP??

Re:interesting

[mikemcc]

Microsoft was not a driving force behind XML-RPC. That credit goes to Dave Winer of Userland Software. http://www.xmlrpc.org/spec

XMP-RPC predates SOAP, and in fact was a major inspiration for SOAP. If you look at the specification for the latter protocol, http://www.w3.org/TR/SOAP/ , you will see that Dave Winer is one of the eight authors credited.

I have not seen anything which indicates that MS "lost control" of SOAP. MS engineers are 4/8 of the credited authors behind the SOAP 1.1 protocol, and MS's entire "Web Services" initiative depends heavily on SOAP.

Re:interesting

[Schwarzchild]

Correct me if I'm wrong, but XML-RPC is a much ligher-weight XML competitor to SOAP-RPC.

Correct. XML-RPC only implements simple containers for vars while SOAP presumably allows data structures like arrays, lists, etc.

IIRC SOAP was created by Dave Winer and Microsoft because there was some need for passing more than a simple but Winer still pushes both protocols even though it seems like he prefers XML-RPC.

same as any other RPC

[mikemcc]

For the potential use of XML-RPC, consider the general benefits of any RPC mechanism. Now consider the benefits of a universally agreed upon specification and syntax.

Because of its XML nature, XML-RPC is verbose, and not suited for high performance RPC activities like NIS/NFS. But if your computer needs a bit of information from a remote data source, and you don't waiting a few milliseconds for that data - and you don't know or care what OS that remote data source is running - then XML-RPC is a good option.

Wot's Uh... The Deal

[ffatTony]

I agree with what you're saying, but what about corba? I realize it is harder, but it seems like a more performance friendly solution, although I admit XML-RPC is more elegant. Perhaps the next corba spec will use xml for communication, although I truly hope not, unless some sort of compression/decompression is performed to reduced transit times.

Re:Wot's Uh... The Deal

[the eric conspiracy]

Corba is a fscking b*tch to implement. XML-RPC is far more elegant and thus we have many more implementations (usually free) to choose from.

"Interceptors"

[Hard_Code]

I wrote a patch which adds "interceptors" ("filters", whatever) to the library, which allow manipulation of the data stream and arguments.

http://aeolus.cit.cornell.edu/xmlrpc.html

I posted this to both lists, and so far nothing as far as responses.

Why Java?

[Anonymous Coward]

Java is nice but I don't always want to use it. For me, I would rather see this RPC-XML for Apache invoke a unix command that has the same name as the RPC funtion being called (in a chroot jail, of course). This would be like CGI. Then you can use any language!!

Of course, starting a process is slow for each function call so the next step up would like me provide my own .so which contains the functions. -- again no Java.