Re: The Revenge of the Geeks

From: Arne Vajh°j <arne_at_vajhoej.dk>
Date: Sun, 27 Jan 2013 19:37:50 -0500
Message-ID: <5105c860$0$288$14726298_at_news.sunsite.dk>



On 1/26/2013 11:54 PM, BGB wrote:
> 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.
>> 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?

Because in the big picture compatibility is important and the potential improvements are not.

Arne Received on Mon Jan 28 2013 - 01:37:50 CET

Original text of this message