Jini Spec

[Peter Firmstone <ji...@zeus.net.au>]

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
>

Re: Jini Spec

[Tom Hobbs <tv...@googlemail.com>]

+1 Peter.  But just to clarify one or two points.

> I don't think it's in our interest for PMC members to act as proxies,

"The Apache Way" expressly prohibits acting as proxies for some
external entity.  As members of the PMC we're expected/required to
always do what is best for the project.

Of course, that's not say that if you're employed by X and X would
like feature Y, we/you can't introduce feature Y.  If feature Y is
good for the project and you've got the time (company X time or
personal) to do feature Y, then go for it.  The problems start when
there are disagreements about whether feature Y should be in the
project or not.  As an individual, you might get lent on by your
employer, but you must wear your Apache PMC hat when making decisions
about the project.  That can be hard, but I don't think we're
experiencing any of that yet.

> final vote will be up to the PMC.

Indeed.  As the PMC for River, like it or not, we're custodians of
both the code and the spec.  Any given individual might not be
interested in a particular topic (notice my lack of involvement when
talking about security and internet available services ;-)  ) and
that's fine.  You might be happy churning out code and not be
interested in maintaining the spec.  Again, fine.  We just have to be
aware that if one group updates the spec, that will have a knock on
effect in the code and vice versa.  So we all need to keep at least a
shallow understanding of what the others are doing.

Regarding "the final vote".  As the project stands at the moment
committers == PMC (as has been pointed out).  So currently, at least,
if you have commit access then you have the backing of the PMC to make
those changes.  I would probably argue that we should be more strict
with the spec updates than with code updates, since they're likely to
have more far reaching effects.  If we ever decide to grant someone
commit rights but not PMC membership then I think that's the time to
decide how we monitor changes to the code and the spec and if we
should treat those two things separately.

For my part, I'm pretty happy with how we're managing changes and
stuff so far.  We might be slow, but I think we're doing a good job!

Cheers,

Tom


On Wed, Nov 9, 2011 at 9:16 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> 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
>>
>
>