Apache River Roadmap

["Herrick, Mike" <Mi...@LibertyMutual.com>]

Hi,

I'm a Jini/JavaSpaces newbie.

I've been observing a bit on this list and am quite excited about the
potential of Apache River.

I lived through years of J2EE, SOA, ESBs, etc. and could have lived
through years of Jini/JavaSpaces - this saddens me.

I view Apache River as the second (and likely final) chance at taking
Jini/JavaSpaces mainstream. I saw somewhere on this list someone
question if this was even a goal. Seems rather insane to me for it NOT
to be the goal. Why else did you torture yourselves getting legal
approval from Sun for Apache 2 license, getting accepted as a podling
etc.? There is a lot of buzz around Jini/JavaSpaces right now - people
are watching and the clock is tick tick ticking.

I mean no offense, I know there are issues being worked out with getting
the code free and clear etc., but how about making a goal of having a
DRAFT Road Map for year 1 in say 2 weeks from now? Not everyone has to
agree, but something - a first rattle out of the gate. Something here
other than what is there now:
http://incubator.apache.org/river/roadmap.html

Step 1: March 1 - Working build with Apache River package names (or
something) 

As I consider investing in Jini/JavaSpaces the trend line of Apache
River is *very* important to me. I'm happy to help a little as learn
more, but I have no idea where to start.

Mike
http://fuzzypanic.blogspot.com/

Re: Apache River Roadmap

[Nigel Daley <nd...@mac.com>]

I'm not sure I have much to add, except to say that I agree with many  
of Dan's *and* Mark's comments.  Perhaps that's because I see them  
working at different levels in parallel.

We each come to this project for different reasons.  In my case, some  
reasons are selfish and some less so.

We also come to this project with different talents and interests.   
Mine happen to be testing - typically a more low level, back-end  
activity.  Others seem to have talent/interest in higher level, up- 
front vision/direction/program management, others in coding/bug  
fixing.  All of these talents and interests are needed and can (and  
should) be applied in parallel.

So, to Dan's original questions trying to address longer term vision/ 
goals (what are we going to do with River? etc.).  Should we have a  
vision/goals?  Yes.  Am I personally interested in helping define/ 
refine them?  Not really, but I hope others have the interest/talent/ 
vision to see this through.  Can other activities occur while goals  
are being defined?  Sure.

Dan, you've already got +1 from a number of people on your comments.  
Perhaps you should open a JIRA (Issue Type Task) and attach an  
initial cut at answering your questions that can then be debated.

Cheers,
Nige

Without a road, why have a map?

[Gregg Wonderly <ge...@cox.net>]

So my only real contribution to this conversation is to say that like Dan, I 
recognize some history of the way discussions occur in this community.  My 
mentioning of the minutea of indentation was just a matter of ordering of events.

I've got plenty of thoughts to throw out about what should and should not happen 
with River from my perspective.  I don't see the point of that yet, because the 
conversation, I fear, would be lost before it was possible to take action on it. 
  So, I'm setting here silent, waiting for something to get started.

Indentation is an issue, I feel the initial codebase should standardize.  So, I 
mentioned it.  Once we have a codebase to work on, and some of my time becomes 
freed from the minutea of work, I'll be better prepared to throw out some more 
thoughts on things which I think would be good for River to consider.

Hopefully we'll get to have conversations such as these before too much longer.

Gregg Wonderly

Re: Apache River Roadmap

[Greg Trasuk <tr...@stratuscom.com>]

Hi folks:

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

Cheers,

Greg.

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

> 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
stuff?"  

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
approaches.

> 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.
http://stratuscom.com

Re: Apache River Roadmap

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Mark Brouwer wrote:
> Dan Creswell wrote:
> 
>>> Also I refuse to let my need for features I require be based on how the
>>> outside world thinks of it. I can only hope it will be appreciated but
>>> that is not my main motivation for contributing here.
>>>
>>
>> Can you clarify that statement please?  From at least one viewpoint,
>> you've just said "I'm only interested in playing with my Jini and I
>> don't care what anyone else thinks".
> 
> I think I said or at least I meant to say was that my requirements for
> enhancements to the Jini technology are a function of my work with Jini
> and that my need is not a function of how this is going to be perceived
> by the larger outside world.
> 
> So if I want a change in PreferredClassLoader to solve a failure
> scenario but it doesn't qualify as a high sex-appeal feature on the
> changelist or won't make headlines then that doesn't matter to me, nor
> do I think it should. The right to propose and discuss that change here
> is important to me, regardless of whether it is going to make Jini more
> relevant to the world in the eyes of most. The process here at the ASF
> will ensure that people involved in the project will have their say
> based on (technical) merit and as such their opinion really matters to
> me, don't get that wrong. But I should not need to apply a 'relevance
> filter' on any of my thoughts before bringing it to the list here. I can
> live though with an answer "Not now, for it doesn't fit our roadmap, so
> please do it in your own copy of the code.".
> 
>>>> The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
>>>> about thus far will not address any of these problems.  If River is not
>>> I would appreciate it if you stop labeling these discussions as being
>>> about minutiae. The last thing we need IMHO is people backing of
>>> discussion about code because it might not fit someones definition of
>>> relevance.
>>>
>>
>> I will not stop labelling it as such because I see no point in messing
>> around with this stuff unless there's a bigger context driving it.  And
>> for me at least that bigger context needs to be about a lot more than
>> just "it fixes a bug" or "it makes the code nicer" or "it makes the code
>> more perfect" etc.
> 
> I think in a collaborative project there is one thing that is very
> important: "respectful, honest, technical-based interaction".
>

Have to refine that some:

"respectful, honest, interaction"

Doesn't have to be (and IMHO shouldn't be just) technical-based
interaction because it's not just about technical issues (at least for
me) as I've been hinting.

> I have no problem with you saying "Maybe it is good idea to decide what
> we are going to do in the bigger context here as that would help a lot
> in going forward.", but your message to the participants on the list was
> "The river-dev list is full of minutae - discussion of coding standards,
> issues on nitty gritty bits of behaviour around locking or
> preferred-lists or when we might get the code drop or testing or
> checkins. But, I don't care about any of this stuff, why? Because it's
> irrelevant."
> 
> It is probably just me being overly sensitive to these kind or words,
> but I have problems seeing this and other remarks in "Drowning in the
> River" as paying respect to your fellow people here. They were certainly
> honest ;-) and your intentions were good I presume, but to me it didn't
> feel good.
> 

Not intending to offend at all - I simply needed to cite some examples
of the kind of stuff I was pointing a finger at otherwise there's no
context for discussion.

>> Maybe I do and maybe I'll get to talking about them one day but I'm much
>> more interested in hearing the "community view", people like Mike or
>> Sean for example and forming a roadmap from that.
>>
>> In absence of such feedback and if there's general interest from other
>> committers I will consider putting them forward.  Otherwise, I will
>> assume the project wants to focus on the kind of things you've put
>> forward in which case I will execute on my ideas elsewhere.
> 
> Dan isn't this project a summation of what people want to do and where
> they want to put their effort in? Maybe the things I want to focus on
> are not the things you or any of the other committers want to focus on,
> but that doesn't mean there is a problem or conflict by definition.
> 

Ah, but I think there is a conflict - as I keep saying (and I see no
consideration from you thus far):

River rightly or wrongly is viewed as being the public face of Jini and
we know that the starter kit/core dev is not a good public face.

That's not a problem so long as we as a group have a strategy for
pushing attention away from River to somewhere else that can be the
public face.

Thus far I see no one willing to discuss that issue.  I see plenty of
other stuff being kicked around but no addressing of this key issue
which IMHO will kill us unless we deal with it.  If we don't deal with
it we will confuse the audience.  Potential developers won't know where
to go nor will potential users.

You want to go one way and I have no problem with you going that way but
 I would like to know if you've spent some time thinking about the cost
of your choices (like what it does to the River image) and whether you
are prepared to help others work around those costs.

> You make it sound that I've decided what the project should or should
> not look like, I hope my postings should have made clear that I don't
> exactly know where the border is, where it should be or which way we

Personally, I'm not sure they have made that clear but thanks, now I get it.

> should go. A lot of that will be determined by those who bring in ideas
> and can back that up with time, therefore I find it strange that while
> you have ideas we have to keep asking for it. By showing your ideas, we
> can see whether we have a problem and if there appears to be a problem
> we can try to solve it.

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

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 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.

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.

Re: Apache River Roadmap

[Mark Brouwer <ma...@cheiron.org>]

Dan Creswell wrote:

>> Also I refuse to let my need for features I require be based on how the
>> outside world thinks of it. I can only hope it will be appreciated but
>> that is not my main motivation for contributing here.
>>
> 
> Can you clarify that statement please?  From at least one viewpoint,
> you've just said "I'm only interested in playing with my Jini and I
> don't care what anyone else thinks".

I think I said or at least I meant to say was that my requirements for
enhancements to the Jini technology are a function of my work with Jini
and that my need is not a function of how this is going to be perceived
by the larger outside world.

So if I want a change in PreferredClassLoader to solve a failure
scenario but it doesn't qualify as a high sex-appeal feature on the
changelist or won't make headlines then that doesn't matter to me, nor
do I think it should. The right to propose and discuss that change here
is important to me, regardless of whether it is going to make Jini more
relevant to the world in the eyes of most. The process here at the ASF
will ensure that people involved in the project will have their say
based on (technical) merit and as such their opinion really matters to
me, don't get that wrong. But I should not need to apply a 'relevance
filter' on any of my thoughts before bringing it to the list here. I can
live though with an answer "Not now, for it doesn't fit our roadmap, so
please do it in your own copy of the code.".

>>> The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
>>> about thus far will not address any of these problems.  If River is not
>> I would appreciate it if you stop labeling these discussions as being
>> about minutiae. The last thing we need IMHO is people backing of
>> discussion about code because it might not fit someones definition of
>> relevance.
>>
> 
> I will not stop labelling it as such because I see no point in messing
> around with this stuff unless there's a bigger context driving it.  And
> for me at least that bigger context needs to be about a lot more than
> just "it fixes a bug" or "it makes the code nicer" or "it makes the code
> more perfect" etc.

I think in a collaborative project there is one thing that is very
important: "respectful, honest, technical-based interaction".

I have no problem with you saying "Maybe it is good idea to decide what
we are going to do in the bigger context here as that would help a lot
in going forward.", but your message to the participants on the list was
"The river-dev list is full of minutae - discussion of coding standards,
issues on nitty gritty bits of behaviour around locking or
preferred-lists or when we might get the code drop or testing or
checkins. But, I don't care about any of this stuff, why? Because it's
irrelevant."

It is probably just me being overly sensitive to these kind or words,
but I have problems seeing this and other remarks in "Drowning in the
River" as paying respect to your fellow people here. They were certainly
honest ;-) and your intentions were good I presume, but to me it didn't
feel good.

> Maybe I do and maybe I'll get to talking about them one day but I'm much
> more interested in hearing the "community view", people like Mike or
> Sean for example and forming a roadmap from that.
> 
> In absence of such feedback and if there's general interest from other
> committers I will consider putting them forward.  Otherwise, I will
> assume the project wants to focus on the kind of things you've put
> forward in which case I will execute on my ideas elsewhere.

Dan isn't this project a summation of what people want to do and where
they want to put their effort in? Maybe the things I want to focus on
are not the things you or any of the other committers want to focus on,
but that doesn't mean there is a problem or conflict by definition.

You make it sound that I've decided what the project should or should
not look like, I hope my postings should have made clear that I don't
exactly know where the border is, where it should be or which way we
should go. A lot of that will be determined by those who bring in ideas
and can back that up with time, therefore I find it strange that while
you have ideas we have to keep asking for it. By showing your ideas, we
can see whether we have a problem and if there appears to be a problem
we can try to solve it.
-- 
Mark

Re: Apache River Roadmap

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Mark Brouwer wrote:
> I'll try keep it short so I skip many things I could have reacted on but
> likely wouldn't add anything new.
> 
> Dan Creswell wrote:
> 
>> Why would I bother to put a spec into River?  If River is going to be
>> this small in focus, I'll develop services and API's elsewhere without
>> bothering to do specifications.
> 
> I think you confuse specification with standard. To me an API of such as
> service is the specification and I see value in people collaborating to
> specify and implement such a service as part of River. As I already
> said. I see no problem in people collaborating to get something done
> here, but they can also do it somewhere else.
> 

I think you assume that I confuse specification and standard.  Actually
I have my own very clear definitions but maybe they aren't the same as
yours. ;)

>> Boring == few developers == project that doesn't need to be at Apache
>> with high visibility and might as well sit on SourceForge in a dark
>> corner.
> 
> The Apache Software Foundation:
> 
>  - provide a foundation for open, collaborative software development
>    projects by supplying hardware, communication, and business
>    infrastructure
>  - create an independent legal entity to which companies and individuals
>    can donate resources and be assured that those resources will be used
>    for the public benefit
>  - provide a means for individual volunteers to be sheltered from legal
>    suits directed at the Foundation's projects
> 
> SourceForge:
> 
>  - provides hardware, communication, and business infrastructure
> 
> So I think there are plenty of reasons why you want to do even 'boring'
> work that needs to be done here opposed to as in a dark corner at
> SourceForge.
> 

The trouble as I keep trying to explain is that River is threatening to
become a hub/key focus for Jini and I contend that if that's the case
should it be solely about the kind of things you describe it will
further damage Jini's image i.e. it will hinder not help.

Basically, River needs to be bigger than this or we need to ensure
people are sent elsewhere (jini.dev.java.net or jini.org) to start with.
 And that's really difficult to do given the spotlight River is under.

>> It might be successful to you but IMHO, having such a thing so visible
>> at Apache will be a PR disaster:
>>
>> "Some quiet little project at Apache that no-one's interested in, that
>> has a couple of committers tinkering away on little things that no-one
>> appears to care about.  Wow, is that all there is to Jini?"
> 
> In my story I talked about a project that provided the foundation for a
> lot of other exiting projects, so that means a lot of people indirectly
> care about this project. I think not that many people download just the
> Linux kernel and then say "wow that is useful".
> 

The linux kernel was interesting to a lot of people that wanted to learn
operating systems or build their own PC or......

That's a pretty wide audience in comparison with the number of people
that might want to learn distributed systems Jini style.  Remember that
most people who use J2EE think they already do distributed systems and
have (supposedly) learnt all there is to learn hence their relative lack
of interest in Jini.

Therefore, I contend that Linux is a bad example in this case because it
had much broader appeal from a generation of programmers and it has to
be said Linus had a certain aura and style that people found attractive.
 If you wanted to play on a "happening" OS on the latest hardware (386)
Linux was really your only option.  If you want to play on "happening"
distributed systems you go use Web Services i.e.  the crowd is against you.

> Also I refuse to let my need for features I require be based on how the
> outside world thinks of it. I can only hope it will be appreciated but
> that is not my main motivation for contributing here.
> 

Can you clarify that statement please?  From at least one viewpoint,
you've just said "I'm only interested in playing with my Jini and I
don't care what anyone else thinks".

Failing that, perhaps you could explain what your main motivation is?

> I believe there is room for things that Sean's Joe the programmer will
> directly comprehend and thinks this is great, as well as for things that
> makes sure that Joe the programmer won't hit the wall at some point in
> time because somebody already thought of that. There is always room for
> people that don't get all the attention but for which you can only hope
> they are there and I hope these kind of people will also be appreciated
> here too.
> 
>> The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
>> about thus far will not address any of these problems.  If River is not
> 
> I would appreciate it if you stop labeling these discussions as being
> about minutiae. The last thing we need IMHO is people backing of
> discussion about code because it might not fit someones definition of
> relevance.
> 

I will not stop labelling it as such because I see no point in messing
around with this stuff unless there's a bigger context driving it.  And
for me at least that bigger context needs to be about a lot more than
just "it fixes a bug" or "it makes the code nicer" or "it makes the code
more perfect" etc.

However, I will happily stop labelling it as such if you can explain
what that bigger context is.

>> If what you describe is the destiny of River as a user and committer, I
>> see minimal value in what the project will be doing.  I might as well
>> take a simple snapshot of the source code and then evolve it and package
>> it independently in a direction I find more useful to customers/users
>> whilst avoiding the need for endless debate with people that want a
>> small quiet project that does little.  I'd also be crossing my fingers
>> that I can attract attention away from River to avoid the PR disaster I
>> mention above.  Kind of sounds like the behaviour of a number of
>> commercial Jini efforts out there using but preferring not to talk about
>> Jini, why?
> 
> I think we should prevent we get some mindset there is a group of people
> that wants to make Jini irrelevant and that there is a group that wants
> to make it relevant and that are obstructed by the first group.
>

Trouble is that as I suggest above your current line of argument could
be viewed as creating exactly such a divide and just because you would
prefer it not to be that way doesn't prevent it from happening.

> Maybe it turns out that in the end our differences all boil down to our
> way with words, there is nothing so inaccurate as natural language
> especially when spoken by people from different countries and different
> personalities.
> 

Maybe - Mark, the reason I'm prepared to expend a number of hours on
this discussion with you is precisely because I value you and assume by
default we are talking past each other due to difference in countries or
language.

> From what you have said so far I can only conclude you have some ideas
> how Apache River can make Jini more relevant, maybe this is a good
> moment to talk about those ideas.
>

Maybe I do and maybe I'll get to talking about them one day but I'm much
more interested in hearing the "community view", people like Mike or
Sean for example and forming a roadmap from that.

In absence of such feedback and if there's general interest from other
committers I will consider putting them forward.  Otherwise, I will
assume the project wants to focus on the kind of things you've put
forward in which case I will execute on my ideas elsewhere.

> Maybe it turns out your ideas for the roadmap align nicely with the
> ideas of others, so we can all work happily together hand in hand!

Thus far, I'm not convinced they do align hence my irritating
questioning of things as a means of discovering what people do want to do.

Dan.

Re: Apache River Roadmap

[Mark Brouwer <ma...@cheiron.org>]

I'll try keep it short so I skip many things I could have reacted on but
likely wouldn't add anything new.

Dan Creswell wrote:

> Why would I bother to put a spec into River?  If River is going to be
> this small in focus, I'll develop services and API's elsewhere without
> bothering to do specifications.

I think you confuse specification with standard. To me an API of such as
service is the specification and I see value in people collaborating to
specify and implement such a service as part of River. As I already
said. I see no problem in people collaborating to get something done
here, but they can also do it somewhere else.

> Boring == few developers == project that doesn't need to be at Apache
> with high visibility and might as well sit on SourceForge in a dark corner.

The Apache Software Foundation:

  - provide a foundation for open, collaborative software development
    projects by supplying hardware, communication, and business
    infrastructure
  - create an independent legal entity to which companies and individuals
    can donate resources and be assured that those resources will be used
    for the public benefit
  - provide a means for individual volunteers to be sheltered from legal
    suits directed at the Foundation's projects

SourceForge:

  - provides hardware, communication, and business infrastructure

So I think there are plenty of reasons why you want to do even 'boring'
work that needs to be done here opposed to as in a dark corner at
SourceForge.

> It might be successful to you but IMHO, having such a thing so visible
> at Apache will be a PR disaster:
> 
> "Some quiet little project at Apache that no-one's interested in, that
> has a couple of committers tinkering away on little things that no-one
> appears to care about.  Wow, is that all there is to Jini?"

In my story I talked about a project that provided the foundation for a
lot of other exiting projects, so that means a lot of people indirectly
care about this project. I think not that many people download just the
Linux kernel and then say "wow that is useful".

Also I refuse to let my need for features I require be based on how the
outside world thinks of it. I can only hope it will be appreciated but
that is not my main motivation for contributing here.

I believe there is room for things that Sean's Joe the programmer will
directly comprehend and thinks this is great, as well as for things that
makes sure that Joe the programmer won't hit the wall at some point in
time because somebody already thought of that. There is always room for
people that don't get all the attention but for which you can only hope
they are there and I hope these kind of people will also be appreciated
here too.

> The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
> about thus far will not address any of these problems.  If River is not

I would appreciate it if you stop labeling these discussions as being
about minutiae. The last thing we need IMHO is people backing of
discussion about code because it might not fit someones definition of
relevance.

> If what you describe is the destiny of River as a user and committer, I
> see minimal value in what the project will be doing.  I might as well
> take a simple snapshot of the source code and then evolve it and package
> it independently in a direction I find more useful to customers/users
> whilst avoiding the need for endless debate with people that want a
> small quiet project that does little.  I'd also be crossing my fingers
> that I can attract attention away from River to avoid the PR disaster I
> mention above.  Kind of sounds like the behaviour of a number of
> commercial Jini efforts out there using but preferring not to talk about
> Jini, why?

I think we should prevent we get some mindset there is a group of people
that wants to make Jini irrelevant and that there is a group that wants
to make it relevant and that are obstructed by the first group.

Maybe it turns out that in the end our differences all boil down to our
way with words, there is nothing so inaccurate as natural language
especially when spoken by people from different countries and different
personalities.

 From what you have said so far I can only conclude you have some ideas
how Apache River can make Jini more relevant, maybe this is a good
moment to talk about those ideas.

Maybe it turns out your ideas for the roadmap align nicely with the
ideas of others, so we can all work happily together hand in hand!
-- 
Mark

Re: Apache River Roadmap

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Mark Brouwer wrote:
> Hi Mike,
> 
> Thanks for sharing your opinion, it is really interesting to see how
> other watch this pass by.
> 
> Herrick, Mike wrote:
>> Hi,
>>
>> I'm a Jini/JavaSpaces newbie.
>>
>> I've been observing a bit on this list and am quite excited about the
>> potential of Apache River.
>>
>> I lived through years of J2EE, SOA, ESBs, etc. and could have lived
>> through years of Jini/JavaSpaces - this saddens me.
>>
>> I view Apache River as the second (and likely final) chance at taking
>> Jini/JavaSpaces mainstream. I saw somewhere on this list someone
>> question if this was even a goal. Seems rather insane to me for it NOT
>> to be the goal.
> 
> I have no clear view what I want to say to you, besides that I only want
> to show that we at Apache River might be facing an expectation problem.
> Jini is a technology and not a product and as such it requires a
> buy-in by people of the philosophy and concepts.
> 

In your opinion Jini is a technology, not a product.  Perhaps other
people don't view it the same way?

Perhaps other people think it needs to be more "productized"?

> Jini getting mainstream acceptance would mean that (going back to 1999)
> people envision Java (as in bytecode) everywhere and Jini as the vehicle
> to bring services (that allows for proxies based on bytecode) and
> although many people don't dare to say it the Jini Platform everywhere too.
>

No, you shouldn't dare to say it because you would then be seen to be
speaking on behalf of other people with apparent authority.

> Looking at 2007 I see that Java is not everywhere, we have a huge amount
> of PHP, Perl, Python, Ruby, etc. code running that will never be able to
> speak to Jini services and for that reason many people prefer shipping
> plain data (XML, JSON, etc.) that can be parsed/read/interpreted by any
> language. So we've lost a huge piece of the cake here, I can only hope
> that in the future those (often dynamic) languages move to the JVM such
> as with Jython, JRuby so that it would possible to win them back
> (anybody wants to do a proof of concept for "JRuby on Rails talking to a
> JavaSpace"?).
> 
> So that leaves us to Java based systems, well for Jini you need to have
> the Jini Platform available and as many of us know a general J2EE
> application server is a crippled environment due to the fact that what
> Jini requires hasn't become a core part of J2SE and in none of the J2EE
> specfications you can see they have even thought of the concequences of
> having mobile code (it is just an implementation aspect). Java SE/EE
> took a road in favor of the component model instead of the (mobile code)
> service model, although nowadays you get your data shipping SOA (web
> services) for free as part of the core. And don't forget J2ME which is
> also not a Jini friendly environment.
> 
> So we have lost another major part of the cake. From what is left there
> are still many places where Jini could be utilized but I begin to doubt

And we will continue not to get a share of that cake until we get
sufficient "gravity" to encourage that change and we won't get that kind
of gravity if we sit on the side.

You can either accept the world is the way it is or go out and change
it.  Personally I've never been good at acceptance of the status quo.

> whether I can call that mainstream and can be targeted as such. You can
> write vertical frameworks for which you might get thousands of people
> applauding but I won't call that mainstream and I won't call that
> Jini, it will merely make use of Jini.
> 
> Sure it will be possible to buy-in a bit more people with better
> documentation (such as patterns), but still I have a feeling that no
> matter how much documentation we write most people won't understand the
> value if they don't see it right away after reading JiniTM Architecture
> Specification
> http://java.sun.com/products/jini/2.0.2/doc/specs/html/jini-spec.html
> , or the spiced up versions of it. I'm not going to discuss the
> documentation of the starter kit, because IMHO it ain't a starter kit
> for those that want to write a Jini service in 10 minutes, writing more
> documentation won't get them up to speed any faster I guess.
> 
> Here I take some shortcuts, but I think the fact JavaSpaces gets all the
> attention is because in the eyes of many it is the only Jini service
> that brings value to them (the others are just because you need them to
> work with JavaSpaces). There are no other compelling services or you
> have to write them yourselves.
> 

That is until you explain some core benefits of the other services at
which point people get it and buy in.

> So maybe the way forward would be the availability of more types of
> services. E.g. why should I use a JavaSpace if I really want to have a
> high quality distributed FIFO queue, or why do I have to write my own
> Log service, etc. etc. As soon as the portfolio of Jini services grows
> we might attract people looking out for that kind of functionality.
> Utilizing more services might inspire them to write their own systems
> more in line with the Jini philosophy.
> 
> There are a few things that would make the creation of those services
> easier and there are various initiatives around the globe, so I don't
> believe this is an area River should focus on without proving that
> these are not adequate. Although as I said before, if there are a bunch
> of people who want to do that as part of River I doubt whether I'm in
> the position to say they shouldn't.
> 
> Personally I hope we could focus on improvement of the basic
> infrastructure what I always tend to call the Jini Platform plus things
> that are of great value to anyone such as the Jini utilities (decent
> utilities is something River is a nice repository for) and I hope in
> time it can become a breeding ground for new great Service
> specifications such as Queue service, Logger service, etc.
> 

Why would I bother to put a spec into River?  If River is going to be
this small in focus, I'll develop services and API's elsewhere without
bothering to do specifications.

Then I'll wait for the day users ask me to put a spec into River which I
think is a good deal less likely than them asking me to contribute the
service itself to River.  And I think that's less likely than them
continuing to use my service and asking me to enhance it independently
of anything in River because they see that as the fastest way to get
something done rather than being dragged down by the red-tape of working
within River.

I think another interesting question to ask is, what is it about River
that would make it an appropriate body for handling/developing specs?

> But I doubt whether any of the above is something that directly
> correlates to making Jini mainstream and I really doubt whether Joe the
> programmer (BTW nice piece Sean) will get a cozy feeling by.
> 
> It might turn out that River ends up being a boring (in terms of action)
> low level project that delivers the foundation for all those exiting
> things going on elsewhere. If that is the case Apache River is still a
> successful project in my eyes, even while it stays very quit on the
> users list.
> 

Boring == few developers == project that doesn't need to be at Apache
with high visibility and might as well sit on SourceForge in a dark corner.

It might be successful to you but IMHO, having such a thing so visible
at Apache will be a PR disaster:

"Some quiet little project at Apache that no-one's interested in, that
has a couple of committers tinkering away on little things that no-one
appears to care about.  Wow, is that all there is to Jini?"


>> etc.? There is a lot of buzz around Jini/JavaSpaces right now - people
>> are watching and the clock is tick tick ticking.
> 
> Clocks are always like that, and wise men never wear a watch and/or read
> TSS ;-P
> 
>> I mean no offense, I know there are issues being worked out with getting
>> the code free and clear etc., but how about making a goal of having a
>> DRAFT Road Map for year 1 in say 2 weeks from now? Not everyone has to
>> agree, but something - a first rattle out of the gate. Something here
>> other than what is there now:
>> http://incubator.apache.org/river/roadmap.html
>>
>> Step 1: March 1 - Working build with Apache River package names (or
>> something) 
> 
> I hope this is just an example? Changing the package names will have
> a huge impact and consequences for all current users and for those who
> built upon, wrote books, articles etc. against the Sun implementation of
> the Jini Standards. To me this seems to be a task I want to postpone to
> 2 minute before asking for graduation to TLP.

Personally, I see plenty of opportunities for Jini coming over the
horizon.  I spend a lot of time convincing people of it's utility
successfully whilst constantly having to drag behind me a largely
developer unfriendly core which makes the whole process less efficient
than it should be.  There's another class of developer that can see the
benefits for themselves (after putting in far too much hard work to
understand) and then run into the brick wall of the core.

If we are indeed never going to be mainstream so be it but we are
currently failing to convert the small group of interested people into
regular Jini users because of the obstructions we have.  And that means
we have even less adoption than we should have and with fewer users, we
have less feedback and less direction to follow.  And with less
direction, we have fewer developers wanting to become committers. And we
are _failing_.

The kinds of minutae (e.g. PreferredClassLoader changes) we've talked
about thus far will not address any of these problems.  If River is not
going to tackle any of these problems it will be largely irrelevant and
worse, anyone trying to address these problems elsewhere could be
baulked as River goes off in some other esoteric direction.  If River
wishes to be this irrelevant it should go somewhere less visible and
allow some other project to take advantage of the visibility Apache
gives us.  Or what is currently River should become a small, quiet
sub-project of some much bigger thing deserving of and able to leverage
the kudos of being an Apache project.

If what you describe is the destiny of River as a user and committer, I
see minimal value in what the project will be doing.  I might as well
take a simple snapshot of the source code and then evolve it and package
it independently in a direction I find more useful to customers/users
whilst avoiding the need for endless debate with people that want a
small quiet project that does little.  I'd also be crossing my fingers
that I can attract attention away from River to avoid the PR disaster I
mention above.  Kind of sounds like the behaviour of a number of
commercial Jini efforts out there using but preferring not to talk about
Jini, why?

My two cents,

Dan.

Re: Apache River Roadmap

[Mark Brouwer <ma...@cheiron.org>]

Hi Mike,

Thanks for sharing your opinion, it is really interesting to see how
other watch this pass by.

Herrick, Mike wrote:
> Hi,
> 
> I'm a Jini/JavaSpaces newbie.
> 
> I've been observing a bit on this list and am quite excited about the
> potential of Apache River.
> 
> I lived through years of J2EE, SOA, ESBs, etc. and could have lived
> through years of Jini/JavaSpaces - this saddens me.
> 
> I view Apache River as the second (and likely final) chance at taking
> Jini/JavaSpaces mainstream. I saw somewhere on this list someone
> question if this was even a goal. Seems rather insane to me for it NOT
> to be the goal.

I have no clear view what I want to say to you, besides that I only want
to show that we at Apache River might be facing an expectation problem.
Jini is a technology and not a product and as such it requires a
buy-in by people of the philosophy and concepts.

Jini getting mainstream acceptance would mean that (going back to 1999)
people envision Java (as in bytecode) everywhere and Jini as the vehicle
to bring services (that allows for proxies based on bytecode) and
although many people don't dare to say it the Jini Platform everywhere too.

Looking at 2007 I see that Java is not everywhere, we have a huge amount
of PHP, Perl, Python, Ruby, etc. code running that will never be able to
speak to Jini services and for that reason many people prefer shipping
plain data (XML, JSON, etc.) that can be parsed/read/interpreted by any
language. So we've lost a huge piece of the cake here, I can only hope
that in the future those (often dynamic) languages move to the JVM such
as with Jython, JRuby so that it would possible to win them back
(anybody wants to do a proof of concept for "JRuby on Rails talking to a
JavaSpace"?).

So that leaves us to Java based systems, well for Jini you need to have
the Jini Platform available and as many of us know a general J2EE
application server is a crippled environment due to the fact that what
Jini requires hasn't become a core part of J2SE and in none of the J2EE
specfications you can see they have even thought of the concequences of
having mobile code (it is just an implementation aspect). Java SE/EE
took a road in favor of the component model instead of the (mobile code)
service model, although nowadays you get your data shipping SOA (web
services) for free as part of the core. And don't forget J2ME which is 
also not a Jini friendly environment.

So we have lost another major part of the cake. From what is left there
are still many places where Jini could be utilized but I begin to doubt
whether I can call that mainstream and can be targeted as such. You can
write vertical frameworks for which you might get thousands of people
applauding but I won't call that mainstream and I won't call that
Jini, it will merely make use of Jini.

Sure it will be possible to buy-in a bit more people with better
documentation (such as patterns), but still I have a feeling that no
matter how much documentation we write most people won't understand the
value if they don't see it right away after reading JiniTM Architecture
Specification
http://java.sun.com/products/jini/2.0.2/doc/specs/html/jini-spec.html
, or the spiced up versions of it. I'm not going to discuss the
documentation of the starter kit, because IMHO it ain't a starter kit
for those that want to write a Jini service in 10 minutes, writing more
documentation won't get them up to speed any faster I guess.

Here I take some shortcuts, but I think the fact JavaSpaces gets all the
attention is because in the eyes of many it is the only Jini service
that brings value to them (the others are just because you need them to
work with JavaSpaces). There are no other compelling services or you
have to write them yourselves.

So maybe the way forward would be the availability of more types of
services. E.g. why should I use a JavaSpace if I really want to have a
high quality distributed FIFO queue, or why do I have to write my own
Log service, etc. etc. As soon as the portfolio of Jini services grows
we might attract people looking out for that kind of functionality.
Utilizing more services might inspire them to write their own systems
more in line with the Jini philosophy.

There are a few things that would make the creation of those services
easier and there are various initiatives around the globe, so I don't
believe this is an area River should focus on without proving that
these are not adequate. Although as I said before, if there are a bunch
of people who want to do that as part of River I doubt whether I'm in
the position to say they shouldn't.

Personally I hope we could focus on improvement of the basic
infrastructure what I always tend to call the Jini Platform plus things
that are of great value to anyone such as the Jini utilities (decent
utilities is something River is a nice repository for) and I hope in
time it can become a breeding ground for new great Service
specifications such as Queue service, Logger service, etc.

But I doubt whether any of the above is something that directly
correlates to making Jini mainstream and I really doubt whether Joe the
programmer (BTW nice piece Sean) will get a cozy feeling by.

It might turn out that River ends up being a boring (in terms of action)
low level project that delivers the foundation for all those exiting
things going on elsewhere. If that is the case Apache River is still a
successful project in my eyes, even while it stays very quit on the
users list.

> etc.? There is a lot of buzz around Jini/JavaSpaces right now - people
> are watching and the clock is tick tick ticking.

Clocks are always like that, and wise men never wear a watch and/or read
TSS ;-P

> I mean no offense, I know there are issues being worked out with getting
> the code free and clear etc., but how about making a goal of having a
> DRAFT Road Map for year 1 in say 2 weeks from now? Not everyone has to
> agree, but something - a first rattle out of the gate. Something here
> other than what is there now:
> http://incubator.apache.org/river/roadmap.html
> 
> Step 1: March 1 - Working build with Apache River package names (or
> something) 

I hope this is just an example? Changing the package names will have
a huge impact and consequences for all current users and for those who
built upon, wrote books, articles etc. against the Sun implementation of
the Jini Standards. To me this seems to be a task I want to postpone to
2 minute before asking for graduation to TLP.
-- 
Mark

Re: Apache River Roadmap

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Greg Trasuk wrote:
> Hi Mike:
> 
> 	Welcome to Jini/River.  Please see comments and questions below.
> 
> Cheers,
> 
> Greg.
> 
> On Thu, 2007-02-08 at 19:44, Herrick, Mike wrote:
>> Hi,
>>
>> I'm a Jini/JavaSpaces newbie.
>>
>> I've been observing a bit on this list and am quite excited about the
>> potential of Apache River.
>>
>> I lived through years of J2EE, SOA, ESBs, etc. and could have lived
>> through years of Jini/JavaSpaces - this saddens me.
>>
>> I view Apache River as the second (and likely final) chance at taking
> I don't know, Java's at 5, and who remembers Windows 1, 2, or 3.0?
> 
>> Jini/JavaSpaces mainstream. I saw somewhere on this list someone
>> question if this was even a goal. Seems rather insane to me for it NOT
>> to be the goal. Why else did you torture yourselves getting legal
>> approval from Sun for Apache 2 license, getting accepted as a podling
>> etc.? There is a lot of buzz around Jini/JavaSpaces right now - people
>> are watching and the clock is tick tick ticking.
>>
> I think the question is whether River is meant to be input or output,
> i.e. should River's deliverables be usable to a casual corporate
> developer, or is the project a toolkit that will be used by others
> (probably container developers, but I'm biased) to build deliverables

Hopefully not just container developers and I'm biased too ;)

I've personally packed Jini into all sorts of things without a container
 (in the classic J2EE style usage) to be seen.  So I guess we're saying
we want an OEM style thing coming out of River but suspect having River
then being a thing with which to drive adoption could be difficult
(market leads OEM's, OEM's don't so easily lead markets).

> that casual users will use?  I suspect we all agree that Jini/Javaspaces
> is a better alternative to SOA/ESB/etc (at least for many use cases), so
> we ought to sell it to the mainstream.  It's just a question of how to
> go about it.  There are differences of opinion out there.
> 
>> I mean no offense, I know there are issues being worked out with getting
>> the code free and clear etc., but how about making a goal of having a
>> DRAFT Road Map for year 1 in say 2 weeks from now? Not everyone has to
>> agree, but something - a first rattle out of the gate. Something here
>> other than what is there now:
>> http://incubator.apache.org/river/roadmap.html
>>
>> Step 1: March 1 - Working build with Apache River package names (or
>> something) 
>>
> So long as you're here, could you suggest a step 2?
>

Or how about a set of stengths and weaknesses in what you see as "Jini".
	- Might be easier to form a roadmap from that and widen the debate some.

Oh actually, it might be interesting to ask "what do you see Jini as?"

> I'm actually not being facetious, I'd like to know the newcomer's
> perspective on (1) what is it that draws you to Jini, and (2) what needs
> to be easier to adopt.
> 
> 
>> As I consider investing in Jini/JavaSpaces the trend line of Apache
>> River is *very* important to me. I'm happy to help a little as learn
>> more, but I have no idea where to start.
>>
>> Mike
>> http://fuzzypanic.blogspot.com/
>>
>>

Dan.

Re: Apache River Roadmap

[Greg Trasuk <tr...@stratuscom.com>]

Hi Mike:

	Welcome to Jini/River.  Please see comments and questions below.

Cheers,

Greg.

On Thu, 2007-02-08 at 19:44, Herrick, Mike wrote:
> Hi,
> 
> I'm a Jini/JavaSpaces newbie.
> 
> I've been observing a bit on this list and am quite excited about the
> potential of Apache River.
> 
> I lived through years of J2EE, SOA, ESBs, etc. and could have lived
> through years of Jini/JavaSpaces - this saddens me.
> 
> I view Apache River as the second (and likely final) chance at taking
I don't know, Java's at 5, and who remembers Windows 1, 2, or 3.0?

> Jini/JavaSpaces mainstream. I saw somewhere on this list someone
> question if this was even a goal. Seems rather insane to me for it NOT
> to be the goal. Why else did you torture yourselves getting legal
> approval from Sun for Apache 2 license, getting accepted as a podling
> etc.? There is a lot of buzz around Jini/JavaSpaces right now - people
> are watching and the clock is tick tick ticking.
> 
I think the question is whether River is meant to be input or output,
i.e. should River's deliverables be usable to a casual corporate
developer, or is the project a toolkit that will be used by others
(probably container developers, but I'm biased) to build deliverables
that casual users will use?  I suspect we all agree that Jini/Javaspaces
is a better alternative to SOA/ESB/etc (at least for many use cases), so
we ought to sell it to the mainstream.  It's just a question of how to
go about it.  There are differences of opinion out there.

> I mean no offense, I know there are issues being worked out with getting
> the code free and clear etc., but how about making a goal of having a
> DRAFT Road Map for year 1 in say 2 weeks from now? Not everyone has to
> agree, but something - a first rattle out of the gate. Something here
> other than what is there now:
> http://incubator.apache.org/river/roadmap.html
> 
> Step 1: March 1 - Working build with Apache River package names (or
> something) 
> 
So long as you're here, could you suggest a step 2?

I'm actually not being facetious, I'd like to know the newcomer's
perspective on (1) what is it that draws you to Jini, and (2) what needs
to be easier to adopt.


> As I consider investing in Jini/JavaSpaces the trend line of Apache
> River is *very* important to me. I'm happy to help a little as learn
> more, but I have no idea where to start.
> 
> Mike
> http://fuzzypanic.blogspot.com/
> 
> 
> 
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com