river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Landis" <sean.lan...@gmail.com>
Subject Re: Drowning in the River
Date Tue, 06 Feb 2007 16:06:48 GMT
I've heard one definition of insanity: Insanity is doing the same
thing over and over again expecting different results.

Jini has survived on technical merits and on the strong dedication and
(dare I say) faith, of a small number of brilliant champions. Jini has
been used to solve some very difficult real-world problems, yet the
broader uptake has yet to materialize.

> WHAT ARE WE GONNA DO WITH RIVER?
>
> And that question leads to a bunch of others for me:
>
> (1)   Who's the audience for River?

The audience for Jini has always seemed to be the Computer Science
elite. Not because we are snobs, but because Jini is damned hard to
get one's head around - in many ways.

Jini is a low level middleware with some incredible and unique
capabilities. My experience is that colleagues understand the value
proposition but struggle understanding how they can apply it to their
problems.

At the level Jini is packaged, there is too much complexity for the
average engineer to handle. The security model, for example, is
brilliant, but it is too much for most people to comprehend. Engineers
are taught to avoid complexity whenever possible. Do we really think
that Joe Engineer is going to apply a technology he can't even
understand?

There are many other examples where Jini demands too much. Most
'normal' engineers can't cross the divide between what Jini provides
and what they need. Jini, as delivered in the Starter Kit, is a long
way from an abstraction that is usable by Joe Engineer. (I am not
going to pander the Jini community other than to say this is the
brightest group of people I've had the opportunity to work with.) We
have to understand that we do not represent normal engineers and we
should consider that we may not be representative of the audience for
River.

OTOH, if the scope of River is limited to the abstraction level of the
Starter Kit, then we'd better have a strategy for getting Joe Engineer
on-board through other means. There have been many attempts to cross
the abstraction gap, Valaran, Rio, Seven, etc, etc. Clearly the
Starter Kit is truly just a Starter Kit. I see our audience as either
being:

1) The small group of elite engineers who are willing and able to use
Jini and cross the abstraction gap themselves. This group includes
middleware developers such as the above, as well as those building
in-house solutions like Orbitz.
2) Joe Engineer who demands that the complexity be hidden and the
paths of application be clear.

If I understand things rightly, River should focus on 1), but I think
we need to address 2 as much as is feasible. I think River can help
with 2.

> (2)   What are we going to deliver to that audience?

Clearly the core technology is center stage in whatever form the
Starter Kit takes. I think much of the criticism of the Starter Kit
has to do with the desire to have it usable by both of the above
audiences. If we are clear about who the real audience is for the
Starter Kit, maybe we can let go of some unrealistic expectations.
That's not to say the Kit can't be improved...it is hard to use. I
just don't think Joe Engineer really is ever going to be happy using
Jini at that level.

So what can River do to attract the large number of developers who are
alienated by the complexity of Jini?

I recall when I was touting space-based computing at a previous, large
employer. I explained how spaces worked and all I saw were glazed
eyes. When I started enumerating the use cases and sketching out how
spaces could be used, then eyes started popping. Of course, JavaSpaces
is a service and IS much easier to get one's brain around, but I think
the point is valid.

I think it is perfectly reasonable to enumerate a number of use cases
for Jini and JavaSpaces with sketches of how one goes about doing it.
River can provide these use cases and can give pointers to where to
look. River doesn't have to bridge the abstraction gap, but I think it
ought to at least point the way.

> (3)   Why would that audience care about what we're delivering?

The pool of elite engineers in the position to use Jini is limited.
We've proven that. The pool of Joe Engineers is large and growing. Up
to now they have no reason to care about Jini because they don't
understand it, don't understand how to apply it to their problems, and
aren't willing to accept the perceived risk of using it. I believe if
that audience could be shown real-world use cases that match their
problems, see a way across the abstraction gap, and be led to projects
that help hide complexity and simplify development, that some will
care.

Let's face it, engineers desire low risk, low complexity, and a
limited number of choices. A typical engineer will choose a poor
solution they can understand over a great solution they can't. OTOH,
many engineers will follow a good trail to understanding if they
believe it will be fruitful. I think the beginning of that path starts
with good use cases as the hook.

> (4)   What should River be about?

I suppose River could take on all the above, but I'm not sure that's a
reasonable goal. River probably ought to focus on what we know today
as the Starter Kit, accepting that the audience is more the elite
engineer, and that there's still room at that level for easing
adoption. I feel it is important that River be a gateway of
understanding for Joe Engineer; a place where s/he could see the value
of Jini and be led to a project or product that provided the
appropriate abstraction level for their needs.

Sean

Mime
View raw message