On 2/9/2011 7:41 AM, Brian Murphy wrote:
On Tue, Feb 8, 2011 at 1:17 PM, Patricia Shanahan<p...@acm.org> wrote:
I don't really know enough about River yet to contribute to a lot of the
futures discussions. On the other hand, I can track down and fix bugs, and
doing so helps me learn about more areas.
...
You seem to me have that increasingly rare respect for
code you didn't originally write; where you dig deep into the
code to understand intent as well as function before declaring
something broken and needing whole-house changes. Your
work with FastList was exemplary. For what it's worth, FastList
was always on the old JavaSpace team's hit list of things that
needed to be re-done; for the exact reasons you've identified.
Unfortunately, there was always some higher priority that needed
to be addressed first. But your analysis of the issues seemed
to be spot on.
The choice between fixing an almost-working implementation and rewriting
using new facilities is always a difficult one, just because there can
be so much temptation to rewrite. It's reassuring to know that FastList
was on the hit list already.
Any opinions on what I should go after next?
...
With respect to attracting users, speaking from personal experience,
I think people would be surprised by the number of companies
using river in their products (for example, my previous company and
my current company). But the fact that Outrigger and Mahalo are single
points of failure is an issue when deciding on a service based
infrastructure; just as the NameNode is similarly an issue for Hadoop.
I suspect then that providing replicated, fault-tolerant implementations
of those two services would at least remove one of the reasons
for rejecting river.
For what it's worth, one of my personal regrets is that we did
the LookupDiscoveryService (Fiddler) and the LeaseRenewalManager
(Norm) instead of focusing on replicating Outrigger and Mahalo;
although I do believe that the EventMailbox (Mercury) has great
value. Of course, hindsight is 20-20, but it seems like river is
providing the opportunity for a "do-over". So maybe the stars
are aligning for this sort of work.
The fact that you've been digging deep into the Outrigger code,
and the fact that Dan Creswell has re-engaged means that, with
respect to JavaSpace implementations in particular, we have two
very knowledgeable, motivated, people now participating. Maybe the
starting point might even be with the Blitz implementation, instead
of Outrigger.
What do others think of this general idea, as a development direction
for River?
As Brian says, it could be implemented in parallel with the Internet
idea. I think it is complementary. In the Internet world there is a
significant risk of losing access to a server without the sort of total
collapse of the infrastructure that would doom the application anyway.
A fault-tolerant transaction manager would be both useful in its own
right, and potentially useful in maintaining coherence among replicated
JavaSpaces. I'm not so sure a fault-tolerant JavaSpaces would be
meaningful without a fault-tolerant transaction manager. For that
reason, it seems to me that TransactionManager should come before
JavaSpaces.
Patricia
