code name alternatives (was Re: Split JavaSpaces and JINI)

[James Grahn <jg...@simulexinc.com>]

Oh, what, you expect me to be helpful? ;-)

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

I know it's more typing if done manually, but lo, Eclipse has gifted us 
with CTRL+SHIFT+O.   And with that, our imports organize.   We can 
afford the decadence of self-explanatory names.

That said, package changes may break a terrific amount of code, so it 
would be best to make a change like that with some other major change 
(like the change from jini to apache.river).

Other opinions welcome, of course.

jamesG

Wade Chandler wrote:
> Any suggestions to go along with the ...? :-D I think code names often work better because acronyms are hard to make up to fit a paradigm, and often the things services do are just so darn hard to sum up in a word. I like the code names. Outrigger makes me think of deep sea fishing (without the barfing) though here it probably was used for a sailing canoe, but I don't know for sure, but Mahalo makes me think that, Mahalo Hawaii, and Reggie makes me think of sports because of Reggie Jackson. Anyways, they are all similar to Tomcat or GlassFish or something...not sure what Tomcat or GlassFish has to do with a sensible name either. I like Rivers services names better :-D
> 
> Wade
> 
>  ==================
> Wade Chandler, CCE
> Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
> http://www.certified-computer-examiner.com
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
> 
> 
> 
> ----- Original Message ----
>> From: James Grahn <jg...@simulexinc.com>
>> To: river-dev@incubator.apache.org
>> Sent: Tuesday, December 9, 2008 4:14:47 PM
>> Subject: Re: Split JavaSpaces and JINI
>>
>> Now there's an aspiration for the Jini->River conversion: sensical names.  
>> Outrigger, mahalo, reggie (okay that one's not so bad, but still), ...
>>
>> jamesG
>>
>> Gregg Wonderly wrote:
>>> Gregg Wonderly wrote:
>>>> Javaspaces is an API in the Jini platform.  Reggie is a service implementing 
>> the Javaspaces API, in River, which provides a piece of, and uses the Jini 
>> platform.
>>> Ooops, its not reggie, but outrigger which I think I correctly referenced 
>> elsewhere in this post.
>>> Gregg Wonderly
>>>
> 
> 

Re: code name alternatives (was Re: Split JavaSpaces and JINI)

[Holger Hoffstätte <ho...@wizards.de>]

James Grahn wrote:
> Oh, what, you expect me to be helpful? ;-)
> 
> 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.

Yes. It's a pretty big turn-off, especially since all terms are from
different languages/cultures. Even when the name is an actual word,
"mercury" is almost guaranteed to be mistaken as the element, not the
messenger.

> It may be boring, but personally I'd prefer descriptive package & jar
> names to code names.

boring is good.

> So:
> Outrigger -> services.space
> Mahalo -> services.transaction
> Reggie -> services.lookup or services.registrar
> and so on (with similar changes to jar names).

yes please!

> That said, package changes may break a terrific amount of code, so it
> would be best to make a change like that with some other major change
> (like the change from jini to apache.river).

yes.

Dennis has already done that, now all that's needed is a working committer
model..if only because the one in place obviously doesn't work.

-h

Re: code name alternatives (was Re: Split JavaSpaces and JINI)

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

One word of warning.....

James Grahn wrote:
> Naturally Outrigger is a reference implementation and not the api

Outrigger is not a reference implementation and never has been.  This is
a common misunderstanding - the spec is the definitive guide to
behaviour and where there are holes in the spec they should be fixed
rather than referring to what Outrigger does as being the answer.

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

Re: code name alternatives (was Re: Split JavaSpaces and JINI)

[James Grahn <jg...@simulexinc.com>]

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

Re: code name alternatives (was Re: Split JavaSpaces and JINI)

[Niclas Hedhman <ni...@hedhman.org>]

On Wed, Dec 10, 2008 at 8:52 AM, James Grahn <jg...@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