[squeak-dev] Re: Re: Maintenance of remote references

Sebastian Sastre ssastre at seaswork.com
Sat Jul 19 13:06:08 UTC 2008


> Interesting point. Perhaps consistency can only be related to 
> autonomy?  
> Then we'd have analogy with Http and URLs and service 
> endpoints -- most  
> often they work but are not guaranteed to always work.
>
Automomy yes. One of the principles to honour for scalable design. Due to the
CAP theorem (see http://citeseer.ist.psu.edu/544596.html) my trade off is on
availability and partition tolerance so giving up on consistency.

That relinquish of consistency cames with a price: contention measures.
So this system will work ruled by the economy of "often works and do something
on exceptions" as you well said and with flexible policies of contention so the
developer have choices.

What I do like of this is the similarity with the real world domains: we live in
societies that often works. Err.. o.O  

...ok here a less controversial one from:
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
"...If they deliver you a drink that is incorrect or nonsatisfactory they will
remake it. If the machine breaks down and they cannot make your drink they will
refund your money. Each of these scenarios describes a different, but common
error handling strategy..."

The fact is that they will often make (so sell) the right drinks.
 
To deliver coffe like drinks is very application level and the error handling
responsibility should be transferred there. That's why I choosed to make it as
flexible as I can for wider applicability.

Right now it have only the simplests ones but could be implemented: message
retry policies, connection policies, connection acceptance policies, inbound
message dispatchal policies, outbound message dispatchal policies, etc.

All those where deliberately considered on RemoteObjects design,

Cheers,

Sebastian




More information about the Squeak-dev mailing list