river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: When com.sun.jini -> org.apache.river [Was: Re: [VOTE] Accept the Starter Kit Contribution from Sun Microsystems]
Date Mon, 04 Jun 2007 09:40:38 GMT
Gianugo Rabellino wrote:

> I see your point, and I understand how backward compatibility matters.
> On the other hand, my main issue is about branding, which has to deal
> with diversity as well. More specifically:
> a) from a branding perspective, it should be clear to users that this
> is Apache River, not Sun's Jini  (or possibly the Apache
> implementation of Sun's Jini specs). This is a clear Incubator
> requirement.
> b) I believe that diversity builds mainly upon neutrality: it's harder
> to find people willing to work on com.sun.* (think competitors), as
> they'd feel they'll be working on Sun stuff, not ASF's.
> c) while I can see your point in changing packages as jumping the
> cliff, sometimes you just have to burn your boats. Yes, River might
> fail incubation, which would mean a mess to the Jini community. On the
> other hand, playing safe with package names might be a sign of missing
> commitment to the community.

I agree and understand your points. But besides that I would like to be
able to transfer bells and whistles while it is easy to do so, I'm also
of the opinion that any disruptive change for the Jini community should
be something that is well thought over and be tested in the field by
some early adopters. To me this seems hard to unite with a quick first
release as has been expressed by some people.

FWIW ome background information for those with a short history with
Jini. From the Davis project (2002) I can remember that Sun developed a
lot of then future specs in the com.sun.jini namespace because it was
not a standard at that time (i.e. they couldn't use the net.jini
namespace) and from what I can remember the namespace refactoring was a
significant one with a lot of impact for early adopters. IIRC there were
discussions in the Technical Oversight Committee about using the
net.jini namespace at an earlier stage to prevent from this happening.

While I think jumping cliff is necessary at some point, when near a
shore I don't want to have a burnt boat with me. I care a lot of the
current installed base and those who invested in the Jini technology
since a long time, which includes the selfish me :-). I want them to be
able to start using and getting confidence in the work of the Apache
River project and I think a good way to achieve that is when they are
able to replace their current binaries and see their systems are still
running fine.

If we can achieve that confidence we will get to the point of doing
disruptive changes (such as the namespace changes, maybe going the a new
minimal version of Java, etc.). That move will bring costs to those with
an installed base, but at least they might justify that by seeing or
even participating in a project that has at least has shown it can act
as a coherent bunch of individuals.

> I see your point, and I fundamentally agree. All I'm asking is that
> package renaming sits somewhere high in the priority list.

I think based on discussions in the past we all see changing name spaces
as a logical consequence of coming to the ASF.

Probably the only disagreement will be with regard to the time at which
we should conduct such an effort (hopefully at that time I can take a
long holiday and we can find one person we supply plenty of beer who is
going to do the job (I think it ain't something that allows for a lot of
parallelism, but no doubt one of the Sun people can tell from previous
experience what it involves). It will also be a good moment to sort out
our whitespace issues (this one is for you Gregg :-P ), etc.

View raw message