Web Services as RPC again!

"An XML web service is, to a first approximation, a wide-area RPC service in which requests and responses are encoded in XML as SOAP envelopes, and transported over HTTP.".
This extract from this piece is so not what I think an XML web service is.
If that is what it is then why not just badge any one of a zillion RPC centric distributed technologies and stick a layer of pointy brackets on top. Why re-invent it? Whats the point?
I think Web Services technology *does* need to be invented because its benefits come from it *not* being a wide-area RPC mechanism. Web servicies are not, as far as I'm concerned, distributed objects. If they are, its all a bit of a waste of time and money reinventing it isn't it?

Patents in e-Commerce - it would be funny if it were not so serious

[via Webmink]. A graphic illustration of the problem.

None of the above

Campaign for a "None of the Above" option on electronic ballots in Ireland.
Personally, I think a "MU" option would be an excellent addition.

Blogging XMLUSA

bloggers who will be blogging next weeks XML USA conference.

anti-links again

About this time last year I was noodling the pros/cons of a machine readable anti-linking mechanism.
Today I found this a really simple suggestion for how to do it with services like tinyurl. Isn't the Web's predisposition towards intermediation a great and wonderful thing?

Web Services are not distributed objects

A big Amen Brother to this piece by Werner Vogels.

Python programming for money

The Shuttleworth Foundation has some Python projects it would like to see done and some money to make it happen in 2004.

And the conclusion is?

A good article, and a well put conclusion:

"Our interest in Python developed from a prototyping standpoint, but we quickly adopted it as the language of choice for our management interface as well as for ad-hoc prototyping of future concepts. Numerous developers have come up to speed with Python quickly, and they have expressed pleasant surprise at the simplicity of the language and how quickly they are able to fulfill functional requirements with it. Moreover, Python's robust string and file handling (as well as its built-in types) make it the language of choice for our user interface. We're quite excited about the potential that Python has given us.

In the future, Python will be looked upon favorably by both the development staff and the company at large, because it has allowed us to respond to customer requests in a fast-paced, rapid development environment. The built-in types, lack of compilation, interactive interpreter and usability of Python have made it the language of choice of many and have raised the bar of excellence when evaluating other languages."

No sign of the googlechop

Its been over a year now and still now sign of 'googlechopped' being googlechopped

Pssst, object oriented design doesn't always work

Works great in the small, less great in the large. What we need is a grand unifying theory of how applications can interact with other applications. God, as far as I'm concerned, does not play DCE with the universe:-)

Thick client web apps and blame allocation

Before getting too excited about the potential of desktop applications that connect to the web but run outside the browser, it is worth considering what might be lost. In particular, the sheer simplicity of apportioning blame, in the event of a malfunction. In a Dilbertian way, this is a very important issue and one that thin client web browsing has brought sharply into focus. The fine art of blame allocation is an ITWorld article on this subject.

Epoz - WYSIWYG editor for Zope

Epoz now does XHTML. Very nice.

XML as legacy?

This article on recent moves towards a standard binary encoding of XML contains the phrase "legacy XML".
I cannot believe how anyone would think it a good idea to have to go back to the back old days of funky binary decoders to understand the bits on the wire.
If XML bulk is killing the performance of your application (and I say "if" - you need to back that up with real data). (1) use standard text compression technology e.g. gzip. If that fails (2) consider not using XML at all.
I would prefer to see application specific syntaxes - like CSS or Relax NG compact syntax - bloom instead of letting the binary encoding genie back out of the bottle. Been there, bought the T-shirt, had troulble opening the packet and when I finally opened it, it was "corrupted" whatever that means :-)

What the heck is "maths frameworking"?

Every John Steinbeck book on Amazon has "maths frameworking" in parentheses after the title. A publishers name? Sure looks weird.

Debugger as tool of last resort

Robert. C. Martin on the two edged sword known as "a good debugger".
Odd, but in my years programming Python, I have never felt the need to fire up the debugger that comes with it. I lived in a debugger when I was a C++ programmer.

Titanic herculean translations

Tim Bray points out a considered piece of language translation where the mechanical choice of 'titanic' has been eschewed for the more apposite 'herculean'. As Tim says, language is a slippery, slippery thing.
Douglas Hofstadter, of Godel, Escher, Bach fame, wrote an entire book centered around the translation of one 28 line French poem by Clément Marot.
Highly recommended if you are interested in language and the difficulty (futility?) of mechanizing the interpertation and translation of natural language.