river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Apache River Roadmap
Date Mon, 12 Feb 2007 13:50:15 GMT
Hi folks:

	I've inserted one or two comments on the discussion below.



On Mon, 2007-02-12 at 07:21, Dan Creswell wrote:
> Mark Brouwer wrote:
> > Dan Creswell wrote:

> After a number of years of participation, this is how I see much of the
> Jini community - no offence is intended to anyone......
> The Jini community is a high-friction community with a capacity for
> endless debate that leads nowhere. 

Which makes us completely compatible with Apache (I used to hang out on
the Tomcat lists).  Oddly enough, the Apache way seems to work.  I
suspect that's because when debate is circular, it's usually irrelevant,
so leading nowhere is alright (minority governments usually do the least
damage).  As soon as someone feels strongly enough to commit code or
propose a vote, then action proceeds.  In change-management terms,
there's got to be a sense of urgency for any change to actually succeed.

>  It has a tendency towards debating
> the theoretical in an attempt to divine some perfect solution in the
> absence of any real-world data. 

I don't know; the old Jini Community Process was all about taking things
that are proven in actual use, and making them community standards.  And
I think that the proliferation of outside projects around ease of use
(I'm thinking of Calum's Neon framework, Harvester, Seven, and Gregg's
deployment containers, as well as the Blitz installer and the JSK
starter scripts) reflect a real desire to try out different approaches
and see what works, rather than debate endlessly over what might be easy
for a new user.

I grant you that it might be time to share some learnings and begin
trying to converge on one or two approaches.

>  It complains it gets little recognition
> but does little to earn it.  It complains that nothing changes whilst
> all the time arguing for everything to stay as it is.
I kind of see your point, but I'm having a hard time deciding if I agree
with it.  Are there any examples of this behaviour you could mention?

> Given I feel this way, why on earth would I communicate my ideas? It's
> going to cost me too much and give me too little.  I'm looking to see if
> River is going to change anything.  Thus far, it seems not and if that's
> the case I'd rather put my energy elsewhere.
> I want a Jini that is adopted broadly, takes the "art" a step forward
> and yes, earns me a reasonable living.  I believe Jini would need to be
> responding to users and real-world needs and whilst it would feature my
> own innovations, those too would be aimed at the real-world.  I have a
> collection of ideas on what those real-world needs are based on my
> experience with building Jini systems in the enterprise.
I totally agree.  Every time I teach a course on J2EE or SOA, I find
myself thinking "How can anyone say Jini is hard after seeing this

Having said that, the first (chronological) thing I'd like to see from
River is continuity and stability after a clean handover of the code
from Sun.  In other words I'd like to see a Jini Starter Kit 2.1 (River)
release.  I suppose we should work out the testing infrastructure at the
same time (distributed architecture using JavaSpaces, anyone?  I can
supply Solaris x86 and Windows XP test-runner environments).

After that, we should talk about the user experience. This would include
some discussion of who the "user" is and what she needs.  Then we can
think about how to resolve those needs, and whether that resolution is
part of River or not.  I think it probably is part of River, but there
are some issues around picking a winner out of a plurality of

> I can certainly do this in a project or product outside of River as can
> others but we need for River to support us in this if only by giving
> crystal clarity to it's own mission which it has yet to do and seems
> largely unconcerned about.
In case of an emergent situation, Aviate, Navigate, and Communicate, in
that order (so said my flying instructor back when I had spare time and
spare money).  I propose that we need to aviate (transfer the code and
do a stable River release of the status quo), while we navigate and
communicate (figure out the longer term destination for Jini and River).

> If River does not do this and it follows your favoured path all those
> projects based on what's done here at River will likely be rendered
> invisible, and die which will not be good for your grand vision a la
> Linux kernel.
> I hope this is clearer in some way,
> Dan.
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.

View raw message