Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <493F3C83.4000608@simulexinc.com>
Date: Tue, 09 Dec 2008 22:50:27 -0500
From: James Grahn <jgrahn@simulexinc.com>
User-Agent: Thunderbird 1.5.0.14 (Windows/20071210)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: code name alternatives (was Re: Split JavaSpaces and JINI)
References: <882577.14762.qm@web33805.mail.mud.yahoo.com>
	 <493F12E9.6020106@simulexinc.com>
 <caf30e2a0812091813q75a41570vb50626b96006b5a6@mail.gmail.com>
In-Reply-To: <caf30e2a0812091813q75a41570vb50626b96006b5a6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Naturally Outrigger is a reference implementation and not the api 
interfaces; my thought was that the full classpath would illuminate 
that, i.e. org.apache.river.services.space

That's to say, it's river's space impl.   Not prohibitive toward others 
writing their own.

On reflection, I intended the "services" package to contain only 
implementations, but perhaps it's natural to want to push the api 
interfaces into those packages as well.   If so, drop the 
implementations into a subpackage (if no better name is thought of, 
'impl' would be a lazy, but reasonably understandable choice).

I obviously don't speak for everyone, but the jini users I approached at 
my company - from a neophytes to a grizzled veteran - all of them liked 
the idea of not having to remember what mahalo was any longer than they 
absolutely had to (indeed, the neophyte remembered it was a service, but 
not /which/ service).

The names do have 8-9 years of inertia, but since we're consigned to 
renaming packages anyway for the change to river, I think it's worth 
consideration.

Moreover, one of the frequently discussed items in the river migration 
is how to make jini/river more approachable for new users.   This would 
be a step in that direction, I think: one less stumbling block, even if 
it's only a minor one.

jamesG

Niclas Hedhman wrote:
> On Wed, Dec 10, 2008 at 8:52 AM, James Grahn <jgrahn@simulexinc.com> wrote:
> 
>> I agree that code names are... at least on par with acronyms in many cases,
>> because acronyms rapidly converge to nonsense too (inserting words to make
>> the acronym distinct, alphabet soup, &c).   But cramming half a dozen code
>> names into a single project seems a bit extreme.
>>
>> It may be boring, but personally I'd prefer descriptive package & jar names
>> to code names.
>>
>> So:
>> Outrigger -> services.space
>> Mahalo -> services.transaction
>> Reggie -> services.lookup or services.registrar
>> and so on (with similar changes to jar names).
> 
> After having had these names around for 8-9 years, I think they should
> just stay. But if we do 'modularization' it can be grouped as
> subprojects along 'functionality' instead. Huh??  Outrigger is not
> JavaSpaces. It is one possible (albeit Reference) implementation of
> the JavaSpaces API. Meaning, I would probably like to see;
> 
> services/
>     javaspaces/
>         api/
>         outrigger/
> 
> I think that tailor for the 'what is that?' confusion that we have
> with all (sub) projects, even if the have declarative names.
> 
> 
> Cheers
> Niclas
>