river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <jgr...@simulexinc.com>
Subject Re: code name alternatives (was Re: Split JavaSpaces and JINI)
Date Wed, 10 Dec 2008 03:50:27 GMT
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
> 

Mime
View raw message