river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: River Musings
Date Tue, 01 Sep 2015 13:55:18 GMT
The bulk rename of com.sun.jini and com.artima to org.apache.river was meant to move the namespace
to the org.apache.river realm. I think it is implicit that the namespace org.apache.river
defines project specific implementations of the net.jini namespace semantics. Remember, the
net.jini namespace is for specification classes, not implementation (refer to the Apache Jini
specifications <https://river.apache.org/doc/spec-index.html>). The further re-organizing
under the org.apache.river namespace - to me - provides little value given the purpose of
the namespace change. I vote to keep the namespace as it is.

If there is the desire to move everything into the org.apache.river namespace (that means
net.jini namespace goes away), thats a different discussion, and one that needs to go up for
a vote (like the previous namespace change went through), and provide specifics as to what
goes where and why. 

A different (but related) topic is project re-organization, to have River conform to conventions
that align themselves to a multi-module project, that reflect the basic architectural elements
of a distributed service (documented here <http://www.rio-project.org/conventions.html>).
I have been (as well as others) pushing for a modularized project for some time, but the modularized
project does not need to remove the net.jini namespace, it would provide structure and organization
over the org.apache.river namespace.

Regards

Dennis

> On Sep 1, 2015, at 927AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
> 
> 
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message