How to start from here?

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

Hi all,

First best wishes for 2007 to you all and Geir thanks for creating the
mailing lists.

Now that we can start with the River project I'm curious to know how to
proceed from here. From the top of my head I come up with the following
items for discussion:

1) source drop and what version. Last public version of the Starter
    kit code, or the latest stable version from Sun repository?

2) to what level of J2SE (Java SE) are we going to restrict ourselves
    at this stage?

3) when to convert from com.sun.jini to org.apache.<river?>, right away
    or after we have accepted patches lingering around the Internet and
    the codebase has stabilized;

4) do we need additional process guidelines, standards, etc.

5) the creation of a road map for the project with short-term and
    mid-term goals, such as (as an example but might reflect my
    opinion):

      - splitting the project in various pieces;
      - defining a platform;
      - support for 'Jini accross the firewall'.

And likely a lot of things more that don't cross my mind at this moment.
Maybe it is a good thing to collect all items to be discussed before
actually discussing them.

Any thoughts,
-- 
Mark

Re: How to start from here?

[Bob Scheifler <Bo...@Sun.COM>]

> 1) source drop and what version. Last public version of the Starter
>    kit code, or the latest stable version from Sun repository?

A similar question around what if any of Sun's issue DB to move over.

> 2) to what level of J2SE (Java SE) are we going to restrict ourselves
>    at this stage?
> 
> 3) when to convert from com.sun.jini to org.apache.<river?>, right away
>    or after we have accepted patches lingering around the Internet and
>    the codebase has stabilized;

(Both of which to me are elements of the goals creation in #5.)

> 5) the creation of a road map for the project with short-term and
>    mid-term goals, such as (as an example but might reflect my
>    opinion):
> 
>      - splitting the project in various pieces;
>      - defining a platform;
>      - support for 'Jini accross the firewall'.

- spec (in)compatibility goals
- replacement if any for the starter kit installer


- Bob

Re: How to start from here?

[Jim Hurley <Ji...@Sun.COM>]

On Jan 6, 2007, at 2:31 AM, Nigel Daley wrote:
:
> Bob, would Sun be willing to continue any testing or offer hardware  
> resources?

(Not Bob, but I'll give it a shot...)

We (Sun) have some testing/hardware resources that we
could probably contribute (it would be more of a short
term vs. long term thing, though).  For example, if we (Apache
River) were to complete some bug fixes/rfes in the near term,
Sun might be able to do some testing to help get out a
release.

We need to discuss a workable testing model that
will work over the long term, though.

-Jim

Re: How to start from here?

[Nigel Daley <nd...@mac.com>]

Geir, what hardware to we have available from Apache on which to run  
builds and tests?  How do other teams handle testing resources?

Bob, would Sun be willing to continue any testing or offer hardware  
resources?

Anyone else?  Is there other hardware resources available for testing?

FWIW, here is how Jini has been tested historically:
<http://weblogs.java.net/blog/nidaley/archive/2006/04/ 
jini_300000_tes.html>
For those to busy to click, think 300,000 tests run on 100 machines  
over a two week cycle.  Then rinse and repeat.  Quality ain't free ;-)

Nige

On Jan 5, 2007, at 7:54 AM, Bob Scheifler wrote:

> Mark Brouwer wrote:
>> Now that we can start with the River project I'm curious to know  
>> how to
>> proceed from here.
>
> Another item for the list is if/how to re-establish automated test  
> execution.
>
> - Bob

Re: How to start from here?

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> Now that we can start with the River project I'm curious to know how to
> proceed from here.

Another item for the list is if/how to re-establish automated test execution.

- Bob

Re: Jini documentation [Was: Re: How to start from here?]

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

Brian Murphy wrote:
> On 1/9/07, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:
> r
>> I must admit, I'm a little concerned about all these rules we seem to
>> want to put in place up front in the absence of experience in this new
>> environment.
> 
> +1

So far I think the request for rules is not that high as one might
conclude from the remark in Dan's posting, but I admit I was the first
one to use that word in the documentation mail. Other than the usage of
JIRA I can't come up with real request for rules. Phil was so kind to
draft a patch and not that many people expressed their opinion about it,
why I ask myself already for a few days.

I guess all of us are eagerly waiting for the initial source drop to get
'coding', but before it is there I don't think it is harmful if we share
opinions about what kind of guidelines we think might be necessary, or
that from adhoc decisions we expect to have them emerge.

A guideline can be modified, no need to carve them in stone, but I think
for people looking to participate it is handy when there is something
that reflects the how we think we want to work. There are engineering
practices used that resulted in the excellent quality of the JTSK and to
the fine standards/specifications we have today. I don't know to what
extend some of the processes used by the Jini team scale in an ASF
project, or even if it is possible to maintain some of them at all, or
whether we should want, but I think at least we should discuss these
things here.

Another example: split or merge? On the Internet I hear talk about
repackaging of the JTSK, I expressed my opinion (although very shallow)
as did Bob and Gregg, everyone else seems to be rather silent on this
matter here. We can change things later, but we know how inertia works,
IMHO it would be nice to have at least some of this discussion before
the ServiceUI and JTSK are checked-in.

Please, please, please, don't read this as an attack on anyone, but so
far I can't say there are many opinions expressed.
-- 
Mark

Re: Jini documentation [Was: Re: How to start from here?]

[Brian Murphy <bt...@gmail.com>]

On 1/9/07, Dan Creswell <da...@dcrdev.demon.co.uk> wrote:

> I must admit, I'm a little concerned about all these rules we seem to
> want to put in place up front in the absence of experience in this new
> environment.

+1

Brian

Re: Jini documentation [Was: Re: How to start from here?]

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

[Sorry, I intended to start a new thread, but failed miserable for
proper email readers]

Dan Creswell wrote:

> And that's all fine but:
> 
> (1)	Realize that all your good work elsewhere mightn't get
> recognized/used if we don't look seriously at the issue.  After all, no
> user community, no interest in all the good stuff Mark has done.

I believe I said it to be important, but with the work up on my sleeves
I must make priorities too. Personally I think there is enough good
documentation about the concepts of Jini, with regard to the hard stuff
I think most people should be shielded of that, or rather unaware, or it
is that hard they have the dig the specs anywhere, but this is another
topic I guess.

But believe me, I won't be a roadblock when others want to go ahead,
only when it is decided javadoc is the wrong place for specifications I
will foam with rage ;-)

> (2)	The stuff that you do elsewhere can make it more difficult to get
> users through the door if it's the wrong choice for them whilst being
> the right choice for you.

That might be very well the case, but I always have great difficulties
valuing that against my own beliefs.

> And I'd say let's get ourselves up and running and worry about this
> issue when we hit it.  There's lots of other stuff that needs doing as well.

I've pipelined a few things that will hit this issue, so for me it is
imminent. But for me it was a roadmap issue not one thing we should
decide upon now.
-- 
Mark

Re: Jini documentation [Was: Re: How to start from here?]

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Mark Brouwer wrote:
> I move to a different subject because I think it is better if we have
> each roadmap item in a separate thread.
> 
> Dan Creswell wrote:
>> Couple of comments inline but I'd like to suggest something of a
>> strategic option.  For me, at this stage, moving the specs around or
>> whatever is a detail (an important one) but I think we need a plan for
>> what we're trying to achieve overall - something like:
>>
>> (1) Figure out what documentation we think we need overall
>>
>> (2) Figure out what we have
>>
>> (3) Figure out how (2) intersects with (1)
>>
>> (4) Fill in the gaps
>>
>> (5) Move it around 'til we like where it all lives
>>
>> Now it might be y'all have answers to the above already in which case,
>> great - let's get 'em all out here.
> 
> It is important to talk about what kind of documentation we need and
> something we should get rolling, but to me it is not a priority and as
> such also not something I expect to spend much time on.
> 

And that's all fine but:

(1)	Realize that all your good work elsewhere mightn't get
recognized/used if we don't look seriously at the issue.  After all, no
user community, no interest in all the good stuff Mark has done.

(2)	The stuff that you do elsewhere can make it more difficult to get
users through the door if it's the wrong choice for them whilst being
the right choice for you.

> The only thing I find important at this stage is whether we are going to
> follow a common rule about how we are going to spec and keep that
> uniform. E.g. if there is maintenance on the lookup and discovery
> specification are we going to move that over in a fashion comparable
> with the newer specs or are we going to defrost the current HTML specs
> to the minimum that we can alter a few paragraphs.
> 

And I'd say let's get ourselves up and running and worry about this
issue when we hit it.  There's lots of other stuff that needs doing as well.

I must admit, I'm a little concerned about all these rules we seem to
want to put in place up front in the absence of experience in this new
environment.  It feels somewhat like trying to write specs before we've
had experience with solving an issue which is an oft-cited failing of
such things as WS-*

Dan.

Jini documentation [Was: Re: How to start from here?]

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

I move to a different subject because I think it is better if we have
each roadmap item in a separate thread.

Dan Creswell wrote:
> Couple of comments inline but I'd like to suggest something of a
> strategic option.  For me, at this stage, moving the specs around or
> whatever is a detail (an important one) but I think we need a plan for
> what we're trying to achieve overall - something like:
> 
> (1) Figure out what documentation we think we need overall
> 
> (2) Figure out what we have
> 
> (3) Figure out how (2) intersects with (1)
> 
> (4) Fill in the gaps
> 
> (5) Move it around 'til we like where it all lives
> 
> Now it might be y'all have answers to the above already in which case,
> great - let's get 'em all out here.

It is important to talk about what kind of documentation we need and
something we should get rolling, but to me it is not a priority and as
such also not something I expect to spend much time on.

The only thing I find important at this stage is whether we are going to
follow a common rule about how we are going to spec and keep that
uniform. E.g. if there is maintenance on the lookup and discovery
specification are we going to move that over in a fashion comparable
with the newer specs or are we going to defrost the current HTML specs
to the minimum that we can alter a few paragraphs.

>> But specs that are required for a reimplementation or that tell you what
>> to expect in the not that less straightforward cases (which my mind
>> always tend to look for) should IMO be where they belong and that is
>> close as possible to the code that I have to my avail in my IDE.
>>
> 
> Hmmm, knowing you as I do, I'm not surprised - me, I prefer the specs
> separate and I cross ref into JavaDoc when I need to.

Can't resist, why should one be surprised ;-) I think it is completely
logical to try to find the semantics of a method at the method level.

Going to a spec to have to find out whether a lease duration can be
negative or even zero should be something the javadoc for the
'duration' argument at the method level should tell me, and the
IllegalArgumentException should make it even more obvious.

I've seen too many bugs lingering in code that were there because the
distance between code and semantics was too far apart. And often I was
not in the position to spank those people responsible for I had to admit
knowing the semantics was a job too much effort for the 21 century man.
-- 
Mark

Re: How to start from here?

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

Greg Trasuk wrote:

> One qualifier on the suggestion; I'd only want specs rolled in with
> generic API's.  For instance the JavaSpaces spec would be fine in the
> net.jini.space package, but not with the Outrigger implementation.

To me that speaks for itself. Outrigger is an implementation of that
Specification but it might end-up with features that are not considered
'Standard'.

I realize the above sentence is flawed as these kind of features will be
specified of course as part of the Outrigger specific specification. The
first net.jini.space package is what we used to call 'Community
Standard' and the latter would be vendor or in this case ASF River
Outrigger specific extensions. But as we are no longer allowed to talk
about 'Community Standard' I think we have another source for confusion.
-- 
Mark

Re: How to start from here?

[Greg Trasuk <tr...@stratuscom.com>]

See small comment interspersed.

Cheers,

Greg.

On Tue, 2007-01-09 at 04:32, Dan Creswell wrote:

> > (Mark Brouwer)
> > But specs that are required for a reimplementation or that tell you what
> > to expect in the not that less straightforward cases (which my mind
> > always tend to look for) should IMO be where they belong and that is
> > close as possible to the code that I have to my avail in my IDE.
> >
> 
> Hmmm, knowing you as I do, I'm not surprised - me, I prefer the specs
> separate and I cross ref into JavaDoc when I need to.
> 
> Ugh, it's a little too subjective for me.
> 

I'd be happier with separate specifications, however that suggestion has
gone over like an iron balloon (translation for non-English speakers: it
was suggested and debated at length, and wasn't taken up by the
community).  So in cases where the API and the specification are
inseparable (like Mark suggests below), I agree with Mark that we may as
well have the spec inside the package documentation.  That way it is
subject to version control and the normal suggest/discuss/vote/commit
process.

One qualifier on the suggestion; I'd only want specs rolled in with
generic API's.  For instance the JavaSpaces spec would be fine in the
net.jini.space package, but not with the Outrigger implementation.

> > I see no problem in moving most of the Lease Specification
> > http://java.sun.com/products/jini/2.1/doc/specs/html/lease-spec.html to
> > the package documentation of net.jini.core.lease as long as people get
> > linked there from an overview about leasing to that package.
> > 
> > 
> Dan.

Re: How to start from here?

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Couple of comments inline but I'd like to suggest something of a
strategic option.  For me, at this stage, moving the specs around or
whatever is a detail (an important one) but I think we need a plan for
what we're trying to achieve overall - something like:

(1) Figure out what documentation we think we need overall

(2) Figure out what we have

(3) Figure out how (2) intersects with (1)

(4) Fill in the gaps

(5) Move it around 'til we like where it all lives

Now it might be y'all have answers to the above already in which case,
great - let's get 'em all out here.

Mark Brouwer wrote:
> Jeff, Gregg,
> 
> First thanks Jeff for not reopening the debate ;-) but to conclude it
> from my side. Here are my ideas and I think 'how to deal with
> documentation/specs' should be on the roadmap.
> 
> With both of you I agree that understanding the big picture ain't that
> easy and for that purpose an introductory walk-through would be the
> proper thing to have. Or a user/developer guide/tutorial that explains
> in lay-mans terms what it is all about.
> 

Indeed.

I suspect we might need some conceptual overview, high-level block diagrams.

Then a walk-through of common components like leases, exporters and stuff.

Then tutorials binding bits together - I'm not in favour of trying to do
everything in one tutorial example although the way Jini is that may be
too lofty of a goal.

> I can recall the Overture release had one, and the current JTSK has one
> for the new stuff as part of the "Jini(TM) Technology Starter Kit Overview"
> 
> But specs that are required for a reimplementation or that tell you what
> to expect in the not that less straightforward cases (which my mind
> always tend to look for) should IMO be where they belong and that is
> close as possible to the code that I have to my avail in my IDE.
>

Hmmm, knowing you as I do, I'm not surprised - me, I prefer the specs
separate and I cross ref into JavaDoc when I need to.

Ugh, it's a little too subjective for me.

> I see no problem in moving most of the Lease Specification
> http://java.sun.com/products/jini/2.1/doc/specs/html/lease-spec.html to
> the package documentation of net.jini.core.lease as long as people get
> linked there from an overview about leasing to that package.
> 
> As Gregg mentioned, the specification for javax.swing also links to the
> Swing tutorial. I don't see why we couldn't provide anchors to tutorial
> like information, as long as these tutorials are agnostic towards the
> framework (whether it is JTSK starter code, RIO, Seven, Harvester, etc.)
> and these tutorials are maintained at the River project. Marking those
> links as being no part of the spec is essential though.

Which just sounds way too complex to achieve.  Might be better not to
back-link like that?

Dan.

Re: How to start from here?

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

Jeff, Gregg,

First thanks Jeff for not reopening the debate ;-) but to conclude it
from my side. Here are my ideas and I think 'how to deal with
documentation/specs' should be on the roadmap.

With both of you I agree that understanding the big picture ain't that
easy and for that purpose an introductory walk-through would be the
proper thing to have. Or a user/developer guide/tutorial that explains
in lay-mans terms what it is all about.

I can recall the Overture release had one, and the current JTSK has one
for the new stuff as part of the "Jini(TM) Technology Starter Kit Overview"

But specs that are required for a reimplementation or that tell you what
to expect in the not that less straightforward cases (which my mind
always tend to look for) should IMO be where they belong and that is
close as possible to the code that I have to my avail in my IDE.

I see no problem in moving most of the Lease Specification
http://java.sun.com/products/jini/2.1/doc/specs/html/lease-spec.html to
the package documentation of net.jini.core.lease as long as people get
linked there from an overview about leasing to that package.

As Gregg mentioned, the specification for javax.swing also links to the
Swing tutorial. I don't see why we couldn't provide anchors to tutorial
like information, as long as these tutorials are agnostic towards the
framework (whether it is JTSK starter code, RIO, Seven, Harvester, etc.)
and these tutorials are maintained at the River project. Marking those
links as being no part of the spec is essential though.
-- 
Mark

Re: How to start from here?

[Gregg Wonderly <gr...@wonderly.org>]

Jeff Ramsdale wrote:

> On 1/8/07, Mark Brouwer <ma...@cheiron.org> wrote:
...
>> Also I am of the opinion that the specs (was are no longer community
>> standards) should be maintained at the River project. Having the specs
>> at Jini.org can bring confusion and is extra work if you want to keep
>> them in sync.
> 
> Right. Keeping them in sync isn't what I was suggesting since I agree
> that's extra work. Rather, maintaining them at Jini.org is what I was
> proposing.
> 
> I've never been a fan of maintaining the specs in JavaDoc. I'd prefer
> DocBook or the wiki or even HTML. But I'm not trying to reopen that
> debate.

What I am wishing for, is a place to go to see all of the stuff linked together 
and allowing discovery of buried information.  With it all in Javadoc, you have 
to know where to start with many things that you'd be able to read across if 
there was a 'starting point' that linked everything together.

I don't know if that's a spec document, or a javadoc overview/guide or what.

But, somehow, there needs to be things you can find on the sun web site in those 
tutorials on swing, security, JNLP etc that provide a way to wonder across 
information that you might not know the terms (packages or classnames etc) to 
use to find it in just javadoc.

Gregg Wonderly

Re: How to start from here?

[Jeff Ramsdale <je...@gmail.com>]

Hi Mark,

On 1/8/07, Mark Brouwer <ma...@cheiron.org> wrote:
> Hi Jeff,
>
> In the furture I hope that we can find the time and energy to move the
> specs into the javadoc in a way similar as was done for all the work
> since the Davis project.
>
> At least for the stuff that requires maintenance (as John McClain did
> with JavaSpaces05) we can do a bit of migration I guess.
>
> Also I am of the opinion that the specs (was are no longer community
> standards) should be maintained at the River project. Having the specs
> at Jini.org can bring confusion and is extra work if you want to keep
> them in sync.

Right. Keeping them in sync isn't what I was suggesting since I agree
that's extra work. Rather, maintaining them at Jini.org is what I was
proposing.

I've never been a fan of maintaining the specs in JavaDoc. I'd prefer
DocBook or the wiki or even HTML. But I'm not trying to reopen that
debate.

Anyway, just offering the Jini.org option to see if it was of value to
the community.

> --
> Mark

Jeff

Re: How to start from here?

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

Hi Jeff,

Jeff Ramsdale wrote:
> There's another alternative. I've added the specifications to the wiki
> at Jini.org: <http://www.jini.org/wiki/Category:Jini_Specifications>.
> The spec pages are locked so they can only be changed by certain
> people (currently me and Jim H). I could set up a group containing
> Apache River committers if the expectation is that the specs will be
> managed by said folk from here forward.
> 
> Perhaps it would be meaningless to host the specs at Jini.org given
> that the Apache River committers would also be spec committers. On the
> other hand, the separation would seem to be healthy both in indicating
> to outsiders that Apache River is not the only implementation and in
> helping the committers keep the two distinct in terms of change
> process.

In the furture I hope that we can find the time and energy to move the
specs into the javadoc in a way similar as was done for all the work
since the Davis project.

At least for the stuff that requires maintenance (as John McClain did
with JavaSpaces05) we can do a bit of migration I guess.

Also I am of the opinion that the specs (was are no longer community
standards) should be maintained at the River project. Having the specs
at Jini.org can bring confusion and is extra work if you want to keep
them in sync.
-- 
Mark

Re: How to start from here?

[Jeff Ramsdale <je...@gmail.com>]

There's another alternative. I've added the specifications to the wiki
at Jini.org: <http://www.jini.org/wiki/Category:Jini_Specifications>.
The spec pages are locked so they can only be changed by certain
people (currently me and Jim H). I could set up a group containing
Apache River committers if the expectation is that the specs will be
managed by said folk from here forward.

Perhaps it would be meaningless to host the specs at Jini.org given
that the Apache River committers would also be spec committers. On the
other hand, the separation would seem to be healthy both in indicating
to outsiders that Apache River is not the only implementation and in
helping the committers keep the two distinct in terms of change
process.

Jeff

On 1/8/07, Bob Scheifler <Bo...@sun.com> wrote:
> Mark Brouwer wrote:
> > Ok, not that it that relevant, but I guess the HTML generated from the
> > initial format has been the starting point for the maintained
> > specifications
>
> Yep.
>
> - Bob
>

Re: How to start from here?

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> Ok, not that it that relevant, but I guess the HTML generated from the
> initial format has been the starting point for the maintained
> specifications

Yep.

- Bob

Re: How to start from here?

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

Bob Scheifler wrote:
>> Another item for the list is how to deal with the specifications that
>> are not in the javadoc, I believe they are in Framemaker format.
> 
> At this point they are all maintained in HTML.

Ok, not that it that relevant, but I guess the HTML generated from the
initial format has been the starting point for the maintained
specifications, or is there another format than what is available from
http://java.sun.com/products/jini/2_1index.html?
-- 
Mark

Re: How to start from here?

[Bob Scheifler <Bo...@Sun.COM>]

> Another item for the list is how to deal with the specifications that
> are not in the javadoc, I believe they are in Framemaker format.

At this point they are all maintained in HTML.

- Bob

Re: How to start from here?

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

Mark Brouwer wrote:

> Now that we can start with the River project I'm curious to know how to
> proceed from here.

Another item for the list is how to deal with the specifications that
are not in the javadoc, I believe they are in Framemaker format.
-- 
Mark