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.