Slashdot Mirror

Well, the intention was not to say that XML is better or the best but to explain what is used for.

So it happens that the history of XML allowed it to be used and distributed easier than LISP s-exps. Any other standard could be used, the usefulness is that at least someone can agree to use it so we don't have to reinvent the wheel everytime.

I think the confusing part is that we are used to working with XML by reading it from a file, and so the risk of attaching it early to a specific format... but with Web Services XML could be streamed on the fly between servers to achieve some level of communication. This could help build new ideas/systems based on what it's agreed on. Meaning that if one system uses one binary representation that is different from my binary representation I have to account for the convertion before I can work with the data.

The little I studied about communication protocols is that you get involved with automata theory, in where you have to account for all posible states where your automata could end up based on a particular stage of your communication protocol. And I just thought that on top of that you still have to account for all possible types of dates or floating point data interpretations and surely it would become a very complex system.

Is not that it's written in stone, new alternatives could always be used and based on the complaints of this thread I'm sure that something will come up. As an example, SOAP was preached as the best solution for distributed RPC calls but it is so extensive that already a simpler alternative has been adopted extensively. Look at XML-RPC it's a good read.

The myriads of hackers on KDE and GNOME applications. I'm particularly fond of Kate, KDE's text editor, which is also a component in many other KDE applications.

Ward Cunningham, the creator of the original wiki idea, and Clifford Adams, the maintainer of one of the first usable wiki engines, UsemodWiki.

Rusty Foster, Dries Buytaert and Rob Malda, who created Scoop, Drupal and Slash, respectively, three very powerful weblog engines I use every day.

Spencer Kimball and Peter Mattis for starting the GIMP. Ton Rosendaal and the rest of the Blender team for proving that proprietary applications can become open source through distributed funding.

Anthony Jones, creator of iRATE, for exploring new ways to discover free music.

Dave Winer of UserLand for developing a simple content syndication format (now RSS 2.0), the MetaWeblog API and the XML-RPC protocol.

Keith Packard of HP for his many improvements to X.

Guido van Rossum for creating Python, Larry Wall for creating Perl and the many people involved in making PHP, and making it useful.

And of course, the many other people involved in all of these programs, and those who built the software infrastructure that made them possible.

Exactly!

But, given that software is a "hand made creation", people (programers) can still decide how to implement a softwae "solution".

I'm saying this because you mentioned SOAP as a barrier of entry, indeed it is somewhat elaborated and covoluted. The alternative is XMLRPC that very well simplyfies what you want to achieve with remote procedure calls over the internet.

And I bet other alternatives are out there ready to be used. It just depends how many people use it and help it achieve critical mass.

My $0.02

• Uses the file system (folders and files) as its content database. blojsom can support any backend storage mechanism through a specific implementation of the BlojsomFetcher interface.
• Allows you to configure the file types that blojsom treats as blog entries (defaults to .txt and .html).
• Permalinks which point to individual blog entries.
• Calendar-based (i.e. year, year/month, year/month/day) navigation of your blog.
• Configurable set of blog directories (per flavor) that get aggregated for the default or / category.
• Customizable flavors. blojsom, out of the box can generate html, rss, rss2, rdf, atom, and text flavors.
• Configurable comment and trackback support for users to leave comments and trackbacks on blog entries.
• Plugin support so that you extend the capabilities of blojsom.
• Web-based Administration for blog functionality such as editing blog properties, categories, and templates.
• Remote posting via XML-RPC and the Atom API. Support for Blogger API, MetaWeblog API, and Atom API.
• Customizable template mechanism. blojsom is very powerful in this area in that you as a developer are allowed to decide what display technology is appropriate for the requested flavor. blojsom currently offers a JSP Dispatcher and a Velocity Dispatcher and .jsp and .vm templates are provided for the HTML and RSS flavors.
  • This allows you to mix-and-match display technologies for your blog. For example, you might want to render HTML through the JSP for that flavor while you might want to render RSS through Velocity for that flavor.
  • Have another display technology youd like to use? Simply extend the BlojsomDispatcher interface and configure a mapping file so that blojsom knows how to map the template extension to the proper dispatcher. Thats it!
• Themes allow you to select a new look for your blog.
• Multi-user support with a single blojsom installation. Multi-user options specific to each user include:
  • Authorization properties for users who can post to an individual blog via XML-RPC.
  • All the blog properties such as blog directory, description, owner, default category mappings, etc.
  • Supported flavors.
  • Flavor-based plugin chains.
  • All the individual plugin configuration files are separate per-user.

It's easily capable of representing objects, platform independent, encryptable (via SSL), compressable (via gzip [and probably SSL as well]), and textual.

The advantages of being textual in your protocols is well laid out in Eric Raymond's book The Art of Unix Programming. He even treats it as a case study.

1) Programming languages based on XML.

I agree

2) XSLT

Have you tried it? I rest my case.

Yup. Tried it. It works for me. I prefer to off-load processing to the client where possible though.

3) SOAP

Okay, initially this actually seemed like a good idea to me, but having thought about it, I really think it sucks. Okay, so it is easier to implement SOAP for a particular platform or programming language, but a wire protocol is like a compiler or an OS kernel in a certain sense - it is okay that it is very hard to write, as long as it is stable and high performance, because it is such a central component.

See XML-RPC if you don't like SOAP.

Hmmm. I'm not sure most scholary works are allowed to just cite arbitrary URLs for inline references or footnotes.

The idea is that you generally have to cite peer-reviewed, published and presented articles; criteria which the majority of web published material simply does not satisfy. Web reading would fall under the "course reading", and would have to be backed up by a "real" reference.

According to my GF (currently working on a Masters in Anthropology) there is a lot of confusion on how to use the web for scholary references. Many people cite URLs in citations that are really just online archives of previously-published work. In this case, noting the URL is like saying which library you checked the article out, and what shelf it was on. If you are an undergrad and cite a URL, it is almost a sure thing that the prof or the TA's will take marks off for improper citations.

There are a few peer-reviewed journals that are (partly or completely) published online, in which case the URL might be a valid citation. This is likely to changed, and it seems the original article was suggesting that we need to handle this case now, before we lose more good work.

In a much smaller way, this is the kind of thing that those involved in the whole blog phenomenon are trying to resolve; making sure that their blog-rolls, trackbacks and search-engine cached pages stay historically maintainable.

• Composite files built at request time,
• The results of running a script,
• Interaction with a web application 1 2 3 4,
• Remote procedure calls and object access 1 2,
• Instant messenger communications, and sometimes
• Static files.

"If you embed Tomcat in your application server, you can simply create contexts and mount them with mod_jk."

...for .NET, and SOAP. People this *is* a Good Thing. As long as you can get two different parties to agree on a schema, you are off and running. Open source version of this is XMLRPC and as far as 'closed' source, I am already running Project Server 2002, which has an XMLRPC implementation in it. Third party clients can parse my Project database (over 500 projects and counting) with an XML Web query and Project Server spits back the results. This stuff kicks ass, and I, for one, am pleased that Microsoft is taking a lead in it.

Ooh! Look! I can put every application known to man in a web browser!

Web browsers are turning into the Emacs of desktop computing, and it's pissing me off. If you want a front-end, write a front-end, possibly in Java. When you need to communicate with the server, open a friggin socket. Or use XWT or some other XML-RPC-based solution.

Oooh! But it's web-based! Fscking marketroids.

jeesh, I mean, that's what hyperlinks were invented for

SOAP

XML-RPC

I'm getting "connection refused" so :

cached XMLRPC

No, you are still wrong. SOAP really has nothing to do with web sites.

It *can* be used by web sites to provide an API for programmatic access to that site's data and functionality, but using SOAP in this manner is actually quite redundant: You can do the same thing without SOAP and in a more architecturally sound manner.

This is beside the point, however. SOAP has nothing to do with the web, or web sites, other than the fact it uses HTTP as it's default transport.

SOAP was a spin-off of XML-RPC. Dave Winer developed XML-RPC as a simple RPC mechanism for Userland Frontier, to allow other applications integrate with it. Microsoft picked XML-RPC up (probably becuase it is very buzzword-compilant, and can easily get through those pesky firewalls), turned it into a RPC mechanism for "objects" - which is a lie, they basically just gave it an extensible type system - and let it loose. See XML-RPC for Newbies for a more detailed early history.

"Um. Kind of like how people are using HTTP and the web for mission critical *manual* data input and presentation?"

No, it is being used for RPC (Remote Procedure Call) - a form of IPC (Inter-Process Communications). This is far more dangerous. People are exposing programmatic interfaces to mission-critical systems. These interfaces allow other computers to manipulate data on those remote mission-critical systems. Think of having direct access to Amex's customer database vs. having access to their web site. It is a massively different situation.

/mike

Have you read the SOAP 1.2 specification lately? Nevermind the XML Schema and HTTP 1.1 specifications which SOAP also uses. These specs are far from "simple". SOAP seems to be slowly turning into an XML version of CORBA. XMLRPC, on the other hand, is simple. The Jabber protocol is even simpler yet - no HTTP transport. Something that starts off simple is usually transformed into something quite different after committees of software development firms get a hold of it. It's in their interest to keep the barrier to entry high.

Google xml-rpc interface

I personally refuse to support and or recommend anyone using SOAP web services due to the patent fiasco. I asked on the xml-rpc list if anyone knew of a xml-rpc gateway and Dave Winer immediately jumped to the challange and put up a public gateway.

Thanx Dave

Sorry, but they did not invent XML or SOAP ... SOAP is a bloated enhancement of XML-RPC.

Ah, but Microsoft was not only involved in creating SOAP, but XML-RPC as well:

• Dave Winer discusses the history of XML-RPC, which was jointly designed by Userland Software, Microsoft and DevelopMentor
• SOAP specification at W3C. Note the employers of the authors. Lotus and IBM signed on at the last minute.

It is hard to argue with XMLRPC's simplicity....

The XMLRPC specification

XMLRPC.org

XMLRPC bindings exist for Perl, Python, Java, Frontier, C/C++, Lisp, PHP, Microsoft.NET, Rebol, Real Basic, Tcl, Delphi, WebObjects and Zope.

It is hard to argue with XMLRPC's simplicity....

The XMLRPC specification

XMLRPC.org

XMLRPC bindings exist for Perl, Python, Java, Frontier, C/C++, Lisp, PHP, Microsoft.NET, Rebol, Real Basic, Tcl, Delphi, WebObjects and Zope.

I think that most of corba/dcom/rni etc. are particularly over complicated. They place a burden on the programmer in the wrong place.

Most but not all. Check out XML-RPC which is an extremely simple yet useful remote procedure call protocol. As its name suggests it passes XML documents between server and client, in this case over HTTP.

There are good XML-RPC implementations for several languages, including Java, C, C++, Python, PHP and TCL (see here for a full list). I implemented the RPC part of a fairly a simple client-server Java application in under a day, without any previous knowledge of XML-RPC.

I think that most of corba/dcom/rni etc. are particularly over complicated. They place a burden on the programmer in the wrong place.

Most but not all. Check out XML-RPC which is an extremely simple yet useful remote procedure call protocol. As its name suggests it passes XML documents between server and client, in this case over HTTP.

There are good XML-RPC implementations for several languages, including Java, C, C++, Python, PHP and TCL (see here for a full list). I implemented the RPC part of a fairly a simple client-server Java application in under a day, without any previous knowledge of XML-RPC.

Just because my brain was caffiene deprived :), doesn't mean SOAP is any better for complex distributed processes, or light enough for simple web services.

Why not write a module that maps a XML DTD to a Java interface, then does the RPC for you?

You really should take a look at SOAP's kissing cousin XML-RPC.

However, if we can also link up diverse scripting environments with SOAP and XML-RPC, there's no reason to worry. Choice is key. Most non-Microsoft scripting languages will never run well inside Microsoft's environment. Make it easy for Perl programmers to participate in SOAP networks without leaving home. Same with Java, Python, Tcl, and everything else.

Focus on the protocols, that's what's important. As long as we invest in diversity, Microsoft can't control. Instead of a one-party-system, let's have an n-party-system. That's how we guarantee choice, eliminate lock-in, and maintain forward motion.

BTW, an interesting detail came out at the open source summit on Tuesday. Dick Hardt of ActiveState reports that Perl does not run well in Microsoft's environment. The problem is that Microsoft's virtual machine is designed to run C-like code, but Perl is not like that.

Now I know the solution, we need a DLL-based open scripting architecture, that allows environments to compile and run scripts and have them call back into the environment, much like the architecture we developed on the Mac in the early 90s. Back then it wasn't so interesting because scripting was still pretty small, it was just us and Apple. Ten years later there's been an explosion, and there's another way, beyond XML-RPC, that's needed to integrate. It can be a tough sell to each individual community, as XML-RPC is, because the benefit is that it makes it easy to bridge to other environments. Most communities tend not to see too well outside their borders. But the larger world wants choice. No matter how great your scripting environment, you will eventually meet someone you want to work with who works in a different environment.

I think there are some efforts in the XML-RPC community and elsewhere to come up with a nice, free service "just like" passport. There is no reason why free tools developed for passport interaction couldn't be modified to use the free version instead (make this an option).

Look at Distributed membership and preferences for a closer look (it is a good place to start). There has been a lot of traffic on their mailing list about this lately. Very interesting stuff!

http://www.xmlrpc.com/stories/storyReader$7

what can i do with xml-rpc or soap? why is it so much better than just plain-old http post? just because it has the correct buzzword juju for today?

Actually, XML-RPC and SOAP both fall under the rubric of web services. Web services allow a program to make a remote procedure call to another machine using some wire protocol (ie XML-RPC or SOAP). The neat part about web services is that they are language neutral. That is, a Perl script on Linux can make remote procedure calls to an NT server running an ASP server. When the Perl script gets the data from the RPC call, the data will be available as a standard Perl datatype. If one were to simply use web pages to do this, every script would have to parse HTML just for that particular call. With web services, the programmer never needs to deal with XML at all.

Check out XML-RPC.com or IBM's developerWorks for more information on web services.

SOAP supports objects. Point to SOAP. SOAP is part of a framework (WSDL) which supports object discovery. Point to SOAP. SOAP is independant of HTTP and can function over any (suitable) transport. Point to SOAP. SOAP is fully specified and well documented. Point to SOAP. SOAP includes error handling similar to exception constructs in modern languages. Point to SOAP.

That's 5-2 to SOAP unless I've miscounted.

Take a look at the XML-RPC spec and the SOAP spec. Oh ... if you are a C coder, don't bother, because XML-RPC is better. If you are a programmer or any other sort of developer with experience in technologies introduced since 1980, you should understand.

The biggest technical security risk in most environments is that Bad Guys can hand programs input that doesn't have the properties that the programs' authors expected, and in networked environments (such as an RPC) there are Bad Guys all over the Solar System who have the means of handing input to your programs (both client and server), and RPC mechanisms have been a popular target for crackers, not that networking in general isn't a target-rich environment. Anybody who provides a new general RPC mechanism and doesn't make the default behavior to be "secure" at least to the extent of safety-checking input is a danger to the community. I don't see any evidence that XML-RPC addresses this problem.

The great thing about XML, besides flexibility and popularity, is that it provides a mechanism for defining valid input, through the use of Document Type Definitions, so parsers can determine whether input is both well-formed and valid. That doesn't mean that everybody writing a program that uses your XML DTD will write it safely, or even if they use a parser that they'll refrain from mismanaging memory, but at least they'll all have a consistent spec for what they need to support, and if they've got an xml parser that they're using, it'll have something to work from.
The XML-RPC Spec doesn't provide a DTD, and provides examples that don't use it. They don't say what resources a conforming call might use, and is pretty sketchy about responses to invalid calls, as well as about what to do with non-existent or invalid responses. Of course, it does help to use an XML parser that itself responds safely to maliciously designed inputs, but that's a job for open-source commonly used code, just as any XML-RPC toolkit built using it is. But with no DTD, it's harder to decide if requests are malformed or invalid, so the author's program needs to do that work itself, which means that 25% of the popular packages won't even bother, because the deadline for the next release is coming, or the overhead of the XML parser makes the dancing pigs GUI skin too slow. And it only takes one widespread dangerous application to carry the next internet worm - you don't want QuakeSter OpenMusic&WeaponsAuction to start DDOSing metallica.com because a buffer overflow in the PayLars feature lets bad guys in (and the distributed database that replaces Napster makes it easy to find people running that client.)

Please, there are so many loose ends on this stuff - give it a full-scale spec, and build enough documentation and API tools that encourage safe use and strongly resist unsafe use. (Of course, that's harder than it sounds - the obvious way to protect against buffer overflows in an environment where all the input is character strings is for the API to (safely, with checking) malloc (or language-appropriately-create-objects) any input objects, so the malicious client can probably find some good resource starvation attack, but that's at least a Denial Of Service rather than an attack that lets the bad guy hand the server some code to run.

So my question is, are there any ideas/plans/etc for integrating xmlrpc into gnome?

Don't overlook XML-RPC, which builds on the XML spec to provide a way of serving data over the web to remote clients.

Then there's RSS, which is a way of serving up a news channel or other changing data. These applications are here and in use. Together, these XML-based technologies will someday provide the data layer for the software agents of the future. Read lately about that new "price-checker" technology? Imagine being the one business that doesn't serve up your product list and pricing to that agent.

An interface from XML to these "hidden" databases is only a matter of time. We're just caught right now at a moment between technologies: the authoring tools don't really exist.
----

How is this different from the likes of XML-RPC, or even Microsoft's SOAP? Wouldn't it make sense for everyone to focus on keeping their 'cool stuff over HTTP' application interfaces as compatible with each other as possible?

I tried looking at the site, but got scared after seeing "paradigm" on the first page...

• It'll not be scalable enough.

  For instance, there will need to be a "compression extension" because XML is verbose, thus making messages large.

• It'll not be robust enough.

  Thus requiring an extension so that messaging can be managed by MTS and/or MSMQ, or WTCTNY (Whatever They Call Them Next Year).

• It'll not integrate well enough with whatever tools they're using next year.

None of the technologies are inherently a problem:

• SOAP doesn't seem to be massively worse than XML-RPC although it's probably not as good as Casbah's LDO system.
• MTS is probably not as good as Encina or Tuxedo, but is doubtless better than the nonexistent TP monitors not being deployed in departmental/workgroup systems
• MSMQ may not be as good as Tuxedo, or as open as Isect, and is merely derivative of IBM MQSeries, but doesn't seem to be too bad, again being better than the asynchronous messaging systems nonexistent in non-big-iron systems

The implementations may be run-of-the-mill and derivative, but they're based on pretty good ideas, which is why it's been pretty easy for MSFT to market them.

What is a massive problem is that what gets deployed next year is liable to be massively incompatible with what is available this year.

In a sense, the only hope for developers that use the stuff is if there is some sort of "mass disconnect" where MSFT gets split into MSFT-1, MSFT-2, MSFT-3, ... and this results in the tools deployed having an extra year to stay vaguely stable...

Note that HP has a bunch of RFPs on Source Exchange that are related to E-speak.

http://www.xmlrpc.com/discuss/msgReader$555

An eye-opener to say the least.

Hey, looks like some guy has already implemented your "SOAPY" in Java. A guy named Don Box says he "just published my first SOAP server in Java. It took me 195 lines including support for M-POST." Onto to SOAPY 2!

URI's are great but they're nowhere near as flexible as what Dave Whiner(of scripting.com fame) has come up with. Check out xml-rpc's website to see how you could do everything you've described and more without having to resort to arcane madness such as CORBA ;) Xml-rpc is quite simple to understand and use. It should have a stellar future. Zope has just integrated it and people have already come up with interfaces for Perl, PHP, ASP, etc.