[FoRK] SOAP vs REST

Fri Apr 11 00:31:48 PDT 2008

silky wrote:
> sometimes i think SDW is a bot designed to combine acronyms in a
> fashion that sounds smart but also remains confusing and impenetrable
> for those humans who are not familiar with them.
>   
Maybe I'm just a Chinese Room?  Come closer so I can read your 
surfaces.  (Has anyone else read "Blindsight" by Peter Watts?  The end 
notes are great!  Have you read "Being No One"?  He references it as a 
"the tougest book I've ever read ... also contains some of the most 
mindblowing ideas I've encountered...   Most authors are shameless 
bait-and-switchers when it comes to consciousness.  Pinker...  Koch...  
Towering above such pussies, Metzinger takes the bull by the balls."  
Lol...)
http://www.amazon.com/Blindsight-Peter-Watts/dp/0765319640  (Or you can 
borrow my copy.)
http://www.amazon.com/Being-No-One-Self-Model-Subjectivity/dp/0262633086

Anyway, Nordquist has me totally stumped every time he posts...
I didn't expect anyone to have the slightest problem with my post, other 
than I have some references to obsolete technology (which became 
embedded in Microsoft software, which I find both amusing and annoying).
> anyway, for mine i prefer basic interfaces [rest]. screw xml.
>
>
>   
And what are you going to send over those interfaces?
What strategies will you use to be architecture, language, operating 
system, storage type, character set, etc. agnostic and tolerant?
What about versioning, exceptions, old code still working with data from 
new code with new features, etc.?
And will your data be decipherable without the code in 20+ years?  Or 
are you going to have two completely different methods of storing data 
to file systems vs. databases vs. interacting with other modules, 
programs, services, servers, etc.?

Conventional wisdom often isn't. 
"Best practice" is often best practice by beginners and other Shallows.
Real best practice is used by Deeps doing real architecture and design.

The mainstream press often discovers these real best practices years or 
decades after they have become old hat for those that need them and when 
countless have suffered through inferior methods and finally complained 
loudly enough.  One of the best examples of this is Message Oriented 
Middleware (MOM).  Every few years, it gets rediscovered and tacked on 
to middleware that was designed incorrectly from the start.  To whit: I 
worked with such an architecture at NCR in the 80's for retail systems 
(registers, servers, credit / inventory links, etc. at department 
stores) on 68020 Unix servers and embedded register systems written in 
Pascal.  (And later at Lexis-Nexis and AOL.)  Then it was tacked on to 
CORBA, late.  And the MS server line.  And HTTP, kind of.  Etc.  IBM MQ 
looks like it is doing it, but no, even though it has a messaging API, 
it's really doing RPC underneath!  (On one project, I spec'd a 
lightweight message queue.  For the client, "message queue" -> IBM MQ, 
for no particularly good reason.  Knowing only real message queues, I 
didn't prevent it.  Predictably, it was terribly slow, and clearly the 
wrong solution on all accounts.)

Oh, sorry, more acronyms and stories of the past.  Darn, didn't get my 
AIR code written tonight.

[Timeout reached.  Bot... err..  Programmer exit.]

sdw
>   
> On Fri, Apr 11, 2008 at 10:04 AM, Stephen D. Williams <sdw at lig.net> wrote:
>   
>> Sometimes I'm glad I stay clear of areas that make me queasy.  I only saw
>> enough CORBA action to know that it was broken.  I did a bit too much DCE
>> RPC programming in SunOS so that when Microsoft pulled it in several years
>> later, I completely ignored their derivative.  I did my own port of Kerberos
>> to HPUX 3 or 4 in about 1990 so I avoided Active Directory later.  OK, bad
>> example, I've just been setting up and debugging Kerberized PKI SSH...
>>
>>  I feel vaguely guilty at not participating in this stuff because I would
>> have howled at many of the design decisions, especially the pre-doc RPC
>> style.  And concentrating on half-duplex, synchronous HTTP rather than on
>> something like BEEP.  (HTTP 1.1 could be used inefficiently to implement
>> something close to BEEP, and some use it that way, but it is not the default
>> SOAP mode which is a great loss.)  I was busy doing other things, and I
>> probably wouldn't have been able to route the Microsoft / IBM juggernaut
>> that seems to have done an Ada on the whole thing.  (I.e. taken some good,
>> but immature ideas and too-quickly inflated them into products with unearned
>> mass.)
>>
>>  Part of my focus now is a completely different direction with RDF-derived
>> data interchange.  XML is OK at low complexities, but a mess further down
>> the spectrum.  Clean XML object/document paired with RDF/triples/n-tuples
>> seems to make sense.  But first, I'm working on a personal utility and
>> building my way up.
>>
>>  More than a year ago we designed and built an XML RDF over BEEP over
>> XML-RPC between Java and C# which worked nicely, if slowly.
>>
>>  sdw
>>
>>
>>
>>  Paul Jimenez wrote:
>>
>>     
>> http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
>>     
>>> Dug this up somewhere and found it still appropriate as I watch the
>>> dev team I joined recently deal with having to evolve and support the
>>> SOAP/XML-RPC API that they used in the intreest of expediency in the
>>> early days. I winced when I saw it first, but lately have grown somewhat
>>> tired of trying to convince philistines of the errors of their ways - it
>>> tires me out and annoys the philistines.
>>>
>>>  --pj
>>>
>>> _______________________________________________
>>> FoRK mailing list
>>> http://xent.com/mailman/listinfo/fork
>>>
>>>
>>>       
>>  --
>>  swilliams at hpti.com http://www.hpti.com Per: sdw at lig.net http://sdw.st
>>  Stephen D. Williams 703-371-9362C 703-995-0407Fax 94043 AIM: sdw
>>
>>
>>
>>  _______________________________________________
>>  FoRK mailing list
>>  http://xent.com/mailman/listinfo/fork
>>
>>     
>
>
>
>   