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

Hugh Perkins wrote:

On 8/11/07, Benjamin Franksen 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