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.

Why?

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,

Peter.

Reply via email to