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 <[EMAIL PROTECTED]> 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
