Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Apache Software

Apache XMLRPC 1.0 Released 28

Posted by Hemos from the new-code-released dept.
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.*."
This discussion has been archived. No new comments can be posted.

Apache XMLRPC 1.0 Released More

Apache XMLRPC 1.0 Released

Comments Filter:
  • 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... (Score:2, Informative)

      by danielrall ( 93166 )
      Or perhaps you don't have a clue what XML-RPC is? Try the spec for clarification. [xml-rpc.org]
      • 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... (Score:2, Informative)

      by sjehay ( 83181 )
      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...

  • Soap (Score:3, Interesting)

    by Karma 50 ( 538274 ) on Saturday December 15, 2001 @12:10AM (#2707240) Homepage

    Is this compatible with SOAP? I thought they were working towards that but there's nothing in the announcement about it ...
  • 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 (Score:2, Informative)

      by thedarkstorm ( 468783 )
      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.

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

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

  • interesting (Score:2, Interesting)

    by thedarkstorm ( 468783 )
    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 (Score:3, Informative)

      by mikemcc ( 4795 )
      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.
    • 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.

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

Slashdot Top Deals

Algebraic symbols are used when you do not know what you are talking about. -- Philippe Schnoebelen

Close