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 14:09:40 GMT

> On Sep 1, 2015, at 9:55 AM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
> 
> 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.
> 

Just to be clear, I agree with Dennis here.

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

I for one would be entirely against losing “net.jini”! 

Greg Trasuk

> 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
View raw message