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.
>
I'm not so sure Patricia. I think you're selling yourself short.
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.
> Any opinions on what I should go after next?
>
> I'm considering going after some of the skipped QA tests.
>
Although continuing with the tests is always a good thing,
if you'd like to try something new, you might consider thinking
about and experimenting with ways to provide a fault-tolerant,
replicated JavaSpace and/or TransactionManager.
I realize that the focus of many folks on this list has been primarily
related to things like an internet based lookup service, security-related
issues, and reformatting the package/artifact structure of the release,
but I believe that a new, fault-tolerant implementation of a JavaSpace
or a TransactionManager may attract both new developers and new
users.
I suspect this work -- which can be done in parallel with the other
work being done -- may be not only challenging and interesting
to a number of developers who have been sitting on the sidelines,
but is probably more accessible and less intimidating than the
security work that's been discussed.
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.
Anyway Patricia, you asked for suggestions regarding things you
might do next. This is my suggestion; again, for what it's worth.
I hope this helps,
Brian
PS To "whet the appetite", you might take a look at,
<http://www.navigators.di.fc.ul.pt/software/depspace/>
