Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Tuesday 05 February 2002 12:27, you wrote:
> Because at any given time code is being written to get 2 endpoints
> communicating, not n endpoints. The developers are in a hurry working
> under unrealistic deadlines and expectations. So, for any 2 endpoints
> and given enough developer stress, an RPC is the right thing (it gets
> the network out of the way quickly, so you can pretend you're writing
> procedural code in a single thread of execution). Even if you had 3 or 4
> endpoints, you can always decompose the comms into pairs (divide and
> conquer as anti-pattern). Then one day you wake up to find you have
> _lots_ of pairs making RPC calls and trying to reorder of repurpose some
> of them (or heaven forbid, their databases) without breaking something
> else somewhere else is extremely difficult; there's too many
> permutations and the network is suddenly not the sum of its parts
> anymore. You're out of control of the code.
But why is this any different to when local procedure calls between software
modules are complicatedly inter-related?
>
> Bill de hÓra
>
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
