Usage of net.jini name space in River [was: Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more]

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
 > Mark Brouwer wrote:
 >> My motivation is to include such an API as part of a Platform for the
 >> motivation given below (from my initial posting):
 >
 > Sorry for being unclear, I understand that, the discussion I was
 > referring to was around the value of keeping everything in the
 > "platform" in the net.jini namespace.

Ah, the "what's in a name" discussion. Below you will find my
recollection of how I think at this moment.

Let me state first that a "platform" definition can be an aggregation of
various name spaces (e.g. the Java SE Platform has java., org.),
although for those parts under the control of the River project that we
considered 'core and sacred API' (I would prefer a better word if I knew
of one) I would like to continue to use the net.jini namespace.

My hope is that we are able to maintain a very clear separation between
specifications and the River implementations of those specifications.
While there is technically nothing against having a spec in
org.apache.river.discovery and the River implementations in
org.apache.river.discovery.<provider> I think for the general audience
(including me) this is a confusing situation. Although the JLS mentions
subpackages they have no semantic effect, but people (so do I) tend to
use them as if they have (maybe superpackages,
http://blogs.sun.com/gbracha/entry/developing_modules_for_development,
will make that even 'worse', again not technically but how people will
use name spaces). Therefore I think that implementations should always
be developed in name space this is in a different branch of the hierarchy.

I also believe that for example a "platform" definition containing stuff
in the net.jini namespaces and org.apache.river.discovery gives it a
*feeling* that some unrelated pieces of API has been bolted on to it,
and might even make it less attractive for others outside the ASF to
include in their public API.

Another thing is that I think *some parts* of the org.apache.river
namespace should be subject to a less strict regime with regard to
compatibility (similar as the com.sun.jini name space). See it as the
namespace to try out new ideas and to keep the ability to alter things
when needed. The net.jini namespace could be reserved then for those
things for which you say "this API is subject to a rather strict
compatibility policy and for the greater benefit of the Jini community".
See it as the River project also being the caretaker for some of the
ideas on which Jini was founded. Maybe even one day we find the strength
to submit parts of the net.jini namespace to the JCP, similar to what
the OSGi did with JSR 291.

Maybe this boils down to my need to 'simulate' the ideas behind the JDP
with regard to Standards without the formal process, maybe the next
thing I say is so naive but I personally find it valuable to use the
net.jini namespace as a special name space where people make decisions
with a larger consciousness.

In this particular case I could even bring up a technical motivation in
that changing com.sun.jini.discovery to net.jini.core.discovery allows
you to modify the API in a incompatible way, implementing the next
version of some of the utilities against this new API and we can
deprecate com.sun.jini.discovery. I know you are going to say that
moving to org.apache.river.discovery would have the same effect, and it
does, but still based on the above I would argue for net.jini.

As a last note I don't think that we will get a proliferation of new API
in the net.jini namespace or the core should be lacking in many areas,
which I doubt. If I could go back in time I would have argued against
some of the current classes in the net.jini namespace and would have
reserved it almost solely for those things that I would have seen as
part of the Platform. Some of the utilities such as LookupDiscovery and
SDM e.g. could have been in the org.jini namespace e.g. as these are
great. Again here there is technically nothing against them being in the
net.jini namespace. But many people like to attach value to a particular
namespace and having too many APIs that serve at different levels makes
it confusing. To the same extent that having everything in one bundle
(JTSK) also often blurs what constitutes Jini.

So after showing the world my darkest thought, I'm very curious to know
what others think.
-- 
Mark

Re: Usage of net.jini name space in River [was: Re: Fundamental problem in handleUnicastDiscovery for SSL and Kerberos and more]

[Mark Brouwer <ma...@cheiron.org>]

Mark Brouwer wrote:

draft always reads differently than receiving it through the mail ...

>                        Some of the utilities such as LookupDiscovery and
> SDM e.g. could have been in the org.jini namespace e.g. as these are
> great

         they are utilities that are not a requirement to have available,
of which you could have different although conceptual similar
specifications, but now it carries the smell of being the only way to
lookup a lookup service or to find another service.
-- 
Mark