couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Fidelman <>
Subject Re: why erlang?
Date Mon, 16 Aug 2010 21:00:38 GMT
Noah Slater wrote:
> On 16 Aug 2010, at 21:38, Miles Fidelman wrote:
>> There have been some of these built on top of HTTP, but the purist in me really dislikes
violating layering.
> I'm a little out of my depth here, but is that really the case? The things you're talking
about sound like patterns to me, not layer-specific details. What makes that pattern any less
applicable at a higher level in the network stack?
well, the whole point of protocol layering is to isolate different 
functions in different layers - as soon as the same function is 
available in multiple layers, things just get very confusing and brittle

a simple example that I think will illustrate the difference (note - 
it's easier to read stacks from the bottom up)

a RESTful stack that doesn't violate layering:

RSS - specific encoding of data
HTTP - client-server protocol - deals primarily with addressing data 
items and encodings
TLS - adds security to a connection
TCP - reliable connections
IP - unreliable datagram transport across multiple networks (glues 
individual networks into an internet)
802.x - unreliable data over a single local network
USB (or whatever) - hardware level device connection


WS-* protocols: try to do everything, including things that are already 
available at lower layers (addressing, security, connections, ...)

essentially, a lot of what the WS-* protocols do is reinvent things that 
have been worked out and incorporated into lower layer protocols - the 
result is that:

1. the WS-* protocols tend to do a poor, and complicated, job of 
functions that are available in lower layers of the network stack, and 
simply ignore those capabilities, and/or,

2. an awful lot of SOAP-based applications generate transactions that 
contain huge numbers of empty XML headers

The impact, in practice:  We recently wrote an application that 
translated OpenSearch formatted queries into SOAP formatted queries, for 
execution by an EBRIM Registry/Repository, and then translated the 
responses back into OpenSearch format (actually RSS).  When you looked 
inside the transactions, you'd see:

a 1-line OpenSearch query turns into 1 line of SQL, surrounded by about 
100 lines of empty XML headers

the response starts as 100+ lines of XML, mostly empty headers, that can 
be compressed into about 10 lines of XML in RSS format

Layering ends up being about managing complexity.  Doing things at the 
right layer simplifies things, doing it at the wrong layer makes things 


In theory, there is no difference between theory and practice.
In<fnord>  practice, there is.   .... Yogi Berra

View raw message