Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4EBAEDA1.8020007@zeus.net.au>
Date: Thu, 10 Nov 2011 07:16:17 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Jini Spec
References: 
 <CAEDB+kUPkGsxK7XvhHEsNsVf=8nDoUDAnU8yZ56=xBgCvRszWA@mail.gmail.com>
	 <E3392E6AF5BCC94D95BB5144483090646E1B55DCF0@IE2RD2XVS551.red002.local>
	 <CAEDB+kVyPx75sDV6jhcog0uamiK4Ws=nBocR3wqJv_vyU6vuVg@mail.gmail.com>
	 <E3392E6AF5BCC94D95BB5144483090646E1B7D9CA5@IE2RD2XVS551.red002.local>
	 <CAEDB+kUz5-O6AxbxNTni9ohrvzo5r1EDyghTDZ_Q6bz9Cpb2mA@mail.gmail.com>
	 <4EB79377.5000705@qcg.nl> <1320691666.9644.259.camel@cameron>
 <4EB86D45.7040609@zeus.net.au> <4EBA52B4.7060404@qcg.nl>
In-Reply-To: <4EBA52B4.7060404@qcg.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sim IJskes - QCG wrote:
> On 08-11-11 00:44, Peter Firmstone wrote:
>
>> I think a cooperatively maintained spec is good, providing motivation
>> for ongoing compatibility among different implementations, without the
>> burden of a standards body.
>
> Yes, and what at stake is here, is: are the PMC members going to act 
> as proxies for external stakeholders, who do not participate in river, 
> or are we free to maintain and develop an implementation as we (PMC) 
> see fit, with only ourselfs as stakeholders. \

I don't think it's in our interest for PMC members to act as proxies, 
however anyone who participates by mail list will have their ideas 
heard, final vote will be up to the PMC.

>
> A different issue (for me at least) is providing a software product, 
> which is divided in a spec and implementation.

In the past we've referred to and interpreted the spec for 
implementation.  I guess it depends on whether we code first document 
later, or document first, then code, I think in both cases, it is still 
useful.

Some problems are difficult enough that creating a spec first produces a 
useful guide for implementation.

Here are some things I'd like to make part of the spec at some point in 
future:

   1. Naming of Jini Service artifacts - Dennis has some good
      documentation for Rio, perhaps he might like to contribute back
      for the spec?
   2. Declarative proxy permissions, including a list of permissions in
      jar files, to inform clients at runtime of the Permissions
      required by proxy's.
   3. Jini 2 security extensions, Secure discovery etc.
   4. DNS-SRV Discovery
   5. Lookup Service extensions to support delayed unmarshalling,
      streaming results and local entry based logical filtering prior to
      unmarshalling.

We still have some very hard problems to solve relating to ClassLoaders, 
class visibility, memory isolation and codebase annotation loss, so 
distributed objects behave intuitively, Gregg works around some of these 
problems at present using MarshalledInstance's.

Other interesting research areas include Codebase Services, discovered 
using DNS-SRV

Cheers,

Peter.
>
> P.S. PMC == committer
>