river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: River Musings
Date Tue, 01 Sep 2015 13:27:24 GMT

My opinion….

- There is “Jini API” - This is the interfaces and implementations that are meant to be
quite long-lasting and define how to build services and clients that are independent of any
particular implementation.  e.g. it should be immaterial whether a service or client runs
under Service Starter, River Container, Rio, StartNow, etc.  They should all work together
if they are written to Jini API.  We might think of this as the external interfaces to the
infrastructure services (registrar, transaction manager, JavaSpaces, eventing API, etc), along
with whatever other classes are necessary to use the infrastructure services, like Entry and
its subclasses, ServiceDiscoveryManager, etc.  These are associated with the solution architecture,
and are currently under “net.ini.*"

- There is “implementation”, which provides all the plumbing to create the individual
service instances.  This is what’s currently under ‘com.sun.ini.*”.  In the original
JTSK, this was intended as “starter kit” material, likely to be replaced by any particular
implementation.  To me, this is a clear mapping: “com.sun.jini.* —> 'org.apache.river.*’

- There may be a case going forward for “Implementation API”, intended for interfaces
that should have a little more permanence.  For example, I could see there being an “org.apache.river.collections”
and “org.apache.river.collections.api”.  But personally, I think that’s a weak case.

- “*.impl” - I tend to reserve for explicit implementation of a service.  For example,
in River-examples, there is “org.apache.river.examples.hello.api” and “org.apache.river.examples.hello.impl”.
 In that case, the “api” sub-package is meant to explicitly denominate the client-side
api for the hello service.

So in terms of recommendations, there are kind of two steps here:

1 - Bulk rename ‘com.sun.jini.*’ to ‘org.apache.river.*’, which is what Dennis did
already.
2 - Discuss renaming, reorganization, modularization, etc.  I started talking about this in
regards to “com.sun.ini.tools” a while ago, but we didn’t move forward because of the
size of the job.  We can probably carry on discussions.

Going forward, the question is - let’s say I feel like I need to create a new library, “neatstuff”,
and I’d like to separate neatstuff’s api from implementation.  Do I make:

Option 1-
	org.apache.river.neatstuff.api
	org.apache.river.neatstuff.impl

Option 2-
	org.apache.river.neatstuff
	org.apache.river.neatstuff.api

Option 3-
	org.apache.river.api.neatstuff
	org.apache.river.neatstuff

Option 4-
	org.apache.river.api.neatstuff
	org.apache.river.impl.neatstuff

For me, purely as a matter of aesthetics, I have a strong preference for (Option 1 or Option
2) over (Option 3 or Option 4), and a mild preference for Option 1 over Option 2.

As well, I’ll state my unifying principle again - someone writing a Jini service or client
has no need to deal with River internals, any more than I need to compile Tomcat in order
to write a web servlet.  So anything in “org.apache.river.api.*” or “org.apache.river.**.api”
should really still be considered river internals.

Cheers,

Greg Trasuk

> On Aug 31, 2015, at 9:41 PM, Patricia Shanahan <pats@acm.org> wrote:
> 
> On 8/31/2015 4:07 PM, Bryan Thompson wrote:
> ...
>> Why use net.jini.* rather than net.river.*?
> 
> Do mean "net.river" rather than "org.apache.river"?
> 
> We have domain names jini.net and river.apache.org, and can base package names on either
of those. If we want to use anything else, we would need to acquire the corresponding domain
name.
> 
> In my opinion, for branding reasons, we should use org.apache.river.* wherever possible.


Mime
View raw message