river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Jini Spec API changes - Design Decision - Important
Date Sun, 02 May 2010 06:15:43 GMT
You might be wondering why my recent changes weren't implemented 
earlier, put simply, vision of hindsight is 20:20.

After reading about the reasons why certain decisions have been over the 
evolution of Jini and now River, I can say that River's API is simply 
brilliant, it was put together by some very bright minds, this doesn't 
mean that it's perfect (anything perfect is obsolete), it does have its 
warts, but it's the closest thing to the future of computing I'm aware of.

On the subject of Design decisions, here's a big one I'd like to propose:

    * Depreciate the Lease Service and include the Jini Surrogate
      Architecture with River.


Well a Lease Service renews a Lease for another Service, however if that 
service fails, the remote Lease Service continues renewing its leases.  
I don't think anything is so reliable that we can guarantee it will not 
fail, therefore the Lease Service contributes to unreliability as it 
violates the Lease contract, that is: when something fails, a lease is 
not renewed and the resources are reclaimed.  Instead a Surrogate could 
maintain a lease for a non java architecture service, when the service 
goes away, so can the Lease.

This discussion excludes the LeaseRenewalManager, which doesn't violate 
the Lease contract, as it renews Leases for remote resources on behalf 
of local applications, simplifying programming.

Best Regards,


View raw message