Re: The Revenge of the Geeks

From: BGB <>
Date: Sat, 26 Jan 2013 22:54:12 -0600
Message-ID: <ke2c01$bu5$>

On 1/26/2013 9:11 PM, Arne Vajh°j wrote:
> On 1/26/2013 8:47 PM, Arved Sandstrom wrote:

>> On 01/26/2013 04:47 PM, BGB wrote:
>>> On 1/26/2013 8:12 AM, Arne Vajh°j wrote:
>>>> On 1/26/2013 12:31 AM, BGB wrote:

>> [ SNIP ]
>>>>> FWIW: I once messed briefly with XML-RPC, but never really did much
>>>>> with
>>>>> it since then, although long ago, parts of its design were scavenged
>>>>> and
>>>>> repurposed for other things (compiler ASTs).
>>>> XML-RPC never really took off. Instead we got SOAP.
>>> I don't really like SOAP...

>> [ SNIP ]

>> I don't know anyone who does, I know I don't. Still, it's what we've
>> got. For well-designed operations and schemas it's not that verbose, not
>> appreciably worse than JSON. Having WSDLs and the ability to validate is
>> useful, although over the years I've come to believe that WSDL-first is
>> an abomination unless the project is extremely structured and
>> disciplined.

>> SOAP is also - still - the only game in town for various security and
>> transactional tasks, even if aspects of WS-Security are atrocious. For
>> true web services I'd use REST almost always, because SOAP actually
>> isn't much to do with the Web at all. But if I need application
>> security, encryption of portions of a message, non-repudiation,
>> transactionality etc,and I'm really doing RPC, I'm using SOAP.
> Standards are rarely optimal.
> people are not too happy about HTTP and SMTP either.

well, luckily there is HTTP 2.0 in development, which "should" be a little better, at least as far as it will Deflate the messages...

(in contrast to HTTP 1.1, it will multiplex the requests and responses over a single socket, and also compress the data).

> But a standard is a standard.
> SOAP got the tools support and all the standards that
> build on top of it.
> We can either accept it and live happy with it or invent
> a time machine and go back to around 1998 and tell a few
> people from IBM and MS how it should be done.

or just blow it off and do whatever...

like, standards are useful so long as they are useful, but otherwise, unless there is some greater reason (mandatory inter-op or orders from above), why bother?

like, unless is better for the project overall (or otherwise benefits the developers in some way), why not just go and do something different?

granted, yes, usually standards are a good thing, but usually these are *good* standards. luckily at least, some of the worse offenders here have gained the fate they deserve. Received on Sun Jan 27 2013 - 05:54:12 CET

Original text of this message