[Haskell-cafe] Re: Re: Haskell vs GC'd imperative languages, threading, parallelizeability (is that a word? :-D )

[Benjamin Franksen]

Hugh Perkins wrote:
> On 8/11/07, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
>> A certain amount
>> of dynamism wrt the message content (high level protocol) is necessary
for
>> systems for which Erlang was designed, namely large distributed control
>> systems with minimum down-times. For large distributed installations it
is
>> a matter of practicality to be able to upgrade one component w/o needing
to
>> recompile (and then re-start) all the other components that it
communicates
>> with -- for systems with expected down-times of 3 Minutes per year it is
a
>> matter of being able to meet the specifications. You'll have a hard time
>> finding high-availability or large control systems which use an IDL
>> approach for communication.
> 
> Hmmm, that's interesting.  I'd never considered lack of typing to be a
> good thing for system robustness before!

I didn't use the term robustness, which is typically used to express how
well a program handles unexpected run-time conditions. What I refered to is
maintainability in the face of continually changing requirements and the
need to gradually upgrade components. (And rest assured I'm normally all
for static typing!)

> Question: to what extent does interface versioning get around this
> problem?  I assume the issue we're trying to address is to be able to
> upgrade clients/servers/peers independently, without losing
> connectivity with unupgraded systems?

Yes (to the latter), and 'to a certain extent' to the former.

> So, using versioned interfaces:
> 
> Initially we have:
> client1   marketinterface1
> server     marketinterface1
> client2   marketinterface1
> 
> Then, we upgrade the server with a new interface, marketinterface2.
> Significantly, we keep the old interface.  So now we have:
> 
> client1   marketinterface1
> server     marketinterface1, marketinterface2
> client2   marketinterface1
> 
> The whole system continues to work: client1 and client2 continue to
> chat with server on marketinterface1.
> 
> Now we upgrade client1:
> 
> client1   marketinterface2
> server     marketinterface1, marketinterface2
> client2   marketinterface1
> 
> ... and client2:
> 
> client1   marketinterface2
> server     marketinterface1, marketinterface2
> client2   marketinterface2
> 
> Finally, we deprecate/remove marketinterface1 from the server:
> 
> client1   marketinterface2
> server     marketinterface2
> client2   marketinterface2

Yes, you can somewhat reduce the impact of an IDL based approach if you
introduce the new interface in addition to the old one (and only deprecate
the old interface after all components have been upgraded). However, this
approach has its limits, especially if you consider large installation with
10s to 1000s of servers and clients (many of them being both at the same
time), especially if upgrades are very frequent due to changing physical
parameters, new requirements, additional instrumentation, etc.

Let us be clear on one point: It is of course not possible for a client to
make use of new features offered by a server if they do not know about
these features. With an IDL approach, knowledge about new features need
re-compilation and usually also new code to handle the new information.
With a dynamic approach, this becomes largely a matter of changing
the /configuration/ of a client, which is a much less disruptive process.

Cheers
Ben