river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: code name alternatives (was Re: Split JavaSpaces and JINI)
Date Sat, 20 Dec 2008 10:05:15 GMT
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 <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

View raw message