check point (was Re: Split JavaSpaces and JINI)

[Jim Hurley <ji...@mac.com>]

I don't think breaking River up into these subprojects will make
things easier, provide value, or further the overall interest in
the project and technology.

This has been a very long thread, and I am concerned that
some may be tuning out due to its length and lack of
specificity and due diligence of actual proposals.  In the
interest of the project, I'd like to ask for posters to first read
through the specifications (available at:
<http://java.sun.com/products/jini/index.html>
or
<http://www.jini.org/wiki/Category:Jini_Specifications>
and read through the code and structure.  There was a comment
by one poster that he "hasn't even bothered to look at the
implementation", and I think if he and others did, there would
be a more educated dialog on the list.

There is certainly plenty of work that we should do in the short
run, for example:
   * finalize the AR2 release
   * complete the Apache River project section, including:
      Documentation, Javadoc, etc
   * fix up the Apache incubator page:
       <http://incubator.apache.org/projects/river.html>
   * really create a 'todo' list for new and interested developers,
      and communicate through the list and the "Get Involved" page
   * etc

Proposals with "meat on the bones" ;-) are all most welcome,
but there doesn't seem to be adequate thought and pre-work
put into them before throwing an idea out on the list and creating
long discussions.

The message of making the entrance into the technology easier is
consistent - it would just be good to vet actual proposals that
have been worked out with effort in advance that address this.

I'm trying to change the tone and focus of the mail list dialog
with this email.  Please don't respond directly to it on the list - I  
don't
think it's healthy for the project and won't engage in a discussion that
won't further advance the project.

-Jim
committer, Apache River incubating project




On Dec 21, 2008, at 2:49 AM, Niclas Hedhman wrote:
> On Sun, Dec 21, 2008 at 3:41 PM, Michael McGrady
> <mm...@topiatechnology.com> wrote:
>> My position is that JavaSpaces has value aside from the objectives  
>> of JINI
>> and should be able to stand alone and to be consistent with JINI  
>> competitors
>> just like RMI is (without discussing the JERI issues).  To do that,
>> JavaSpaces cannot depend on JINI interfaces, even if present JINI  
>> interfaces
>> include things that JavaSpaces must depend upon.  That is  
>> fundamentally
>> where I stand.
>
> So, if I claim that we have subprojects;
>
> Apache River Lease
> Apache River Transaction
> Apache River Entry
> Apache River JavaSpaces
> Apache River Jini Service Platform
>
>
> Would you then be happy?
>
> (Because that is what we in reality have.)
>
>
> Cheers
> Niclas

Re: check point (was Re: Split JavaSpaces and JINI)

[Wade Chandler <hw...@yahoo.com>]

----- Original Message ----

> From: Niclas Hedhman <ni...@hedhman.org>
> To: river-dev@incubator.apache.org
> Sent: Sunday, December 21, 2008 9:24:12 AM
> Subject: Re: check point (was Re: Split JavaSpaces and JINI)
> 
> On Sun, Dec 21, 2008 at 9:43 PM, Jim Hurley wrote:
> > I don't think breaking River up into these subprojects will make
> > things easier, provide value, or further the overall interest in
> > the project and technology.
> 
> I am sure that those are typical things that enough people in a group
> will never manage to agree upon...
>

True. What about the situation where you have a module system such as NB or Eclipse and certain modules only work with different parts of the system. Instead of those modules having dependencies upon other specific APIs, to limit what is found in a sub-projects API list, demonstrates a simple case where it helps. Too, what about other standalone systems which may not need dependencies upon the services themselves, and are just some kind of backend processors which need limited APIs and interfaces to get their work done. Should one have to deploy all things in multiple applications with unique classpaths just to get the benefits of those intefaces. There are always many use cases, and yes of course one can write an Ant target to do these things themselves for their projects, but having Jini in smaller sub-sets or in one big one doesn't matter for the person with a large monolithic classpath.
 
> > This has been a very long thread, and I am concerned that
> > some may be tuning out due to its length and lack of
> > specificity and due diligence of actual proposals.  In the
> > interest of the project, I'd like to ask for posters to first read
> > through the specifications (available at:
> > 
> > or
> > 
> > and read through the code and structure.
> 
> Done all of that. What's your point?
> 

Yes, seems most who have been participating have read things; some obviously have not though. We who have may have more to learn of course. Same with any API.

> > There is certainly plenty of work that we should do in the short
> > run, for example:
> >  * finalize the AR2 release
> >  * complete the Apache River project section, including:
> >     Documentation, Javadoc, etc
> >  * fix up the Apache incubator page:
> >      
> >  * really create a 'todo' list for new and interested developers,
> >     and communicate through the list and the "Get Involved" page
> >  * etc
> 
> Please do... The current "noise" will not interfere with those plans.
> Make it happen.
>

Indeed. Many of us are members of different communities. Were I granted access to the web resources I would do some things now. If you need credentials to allow that access or something to get folks helping you out with those things you can just google for "Wade Chandler" and NetBeans and you should find enough contributions to at least know I know my way around development environments and communities. Now, code patches, I understand, and I'll be submitting some along the way which someone can put in for me to towards committer status, but certain the web pages need updated, and seems you guys need the help as they have been updated in a while it seems.
 
> > I'm trying to change the tone and focus of the mail list dialog
> > with this email.  Please don't respond directly to it on the list - I don't
> > think it's healthy for the project and won't engage in a discussion that
> > won't further advance the project.
> 
> Well, it is a lot more healthier than a silent community and no
> action. Pardon me, but your mail have a very "corporate tone", if you
> know what I mean... If you are not interested, don't read it... but
> please don't tell others to be quiet...
> 
> IMHO, there are tons of small things that needs to be done. And a lot
> of that can be done without much code changes. My "user perspective"
> is perhaps only one of many (incorporate Jini technology into another
> open source project), but from where I am coming from Jini 2.x is hard
> to use, especially compared to maybe another 100 or so open source
> projects that I have crossed path with in a similar fashion. I happen
> to think he reason being that Jini comes from a corporate environment,
> which delivers software in a certain fashion. I also think that by
> stirring up the soup, I can create an "open development" evironment
> where things are less homogenous, has flaws here and there so itches
> can be scratched without breaking everything.
> 
> Too bad you won't engage in discussions, but that is your right.
> 

I'll agree the discussion on Entry not being in spaces etc has run its course, but there is more to this entire discussion than that. We need some specific threads which deal with issues, and more than one person has mentioned different APIs being in JARs albeit in different levels etc, I think the interfaces don't necessarily need to reside with all the different implementation things, and too I don't think all the services need to be in the same JAR. 

But, that is just a small part of the problem along with ironing out the build process. Now, if other threads are started which need input, and the committers are just being silent because us newbies are just making noise then I don't know what that says necessarily, but certainly it isn't healthy, and if you don't want help that is fine, but not necessarily open source or in the open spirit. I don't think anyone wants to work on some code or a project if it
seems they'll be beating their heads against walls to get anything
accepted, and thus the reason many ask and talk about ideas first. We all have limited resources, and getting ideas ironed out a little first to make sure there are some supporters of concepts is much better than wasting time on something everyone immediately hates.

Wade


 ==================
Wade Chandler, CCE
Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org

Re: check point (was Re: Split JavaSpaces and JINI)

[Niclas Hedhman <ni...@hedhman.org>]

On Sun, Dec 21, 2008 at 9:43 PM, Jim Hurley <ji...@mac.com> wrote:
> I don't think breaking River up into these subprojects will make
> things easier, provide value, or further the overall interest in
> the project and technology.

I am sure that those are typical things that enough people in a group
will never manage to agree upon...

> This has been a very long thread, and I am concerned that
> some may be tuning out due to its length and lack of
> specificity and due diligence of actual proposals.  In the
> interest of the project, I'd like to ask for posters to first read
> through the specifications (available at:
> <http://java.sun.com/products/jini/index.html>
> or
> <http://www.jini.org/wiki/Category:Jini_Specifications>
> and read through the code and structure.

Done all of that. What's your point?

> There is certainly plenty of work that we should do in the short
> run, for example:
>  * finalize the AR2 release
>  * complete the Apache River project section, including:
>     Documentation, Javadoc, etc
>  * fix up the Apache incubator page:
>      <http://incubator.apache.org/projects/river.html>
>  * really create a 'todo' list for new and interested developers,
>     and communicate through the list and the "Get Involved" page
>  * etc

Please do... The current "noise" will not interfere with those plans.
Make it happen.

> Proposals with "meat on the bones" ;-) are all most welcome,
> but there doesn't seem to be adequate thought and pre-work
> put into them before throwing an idea out on the list and creating
> long discussions.

Welcome to Apache. There is a long-running tradition to throw in the
crazy ideas first, and then go write the code if there some value to
those ideas. Tossing pre-baked solutions into the community is not
respected here, in fact one Incubation ended abruptly because of it.

> I'm trying to change the tone and focus of the mail list dialog
> with this email.  Please don't respond directly to it on the list - I don't
> think it's healthy for the project and won't engage in a discussion that
> won't further advance the project.

Well, it is a lot more healthier than a silent community and no
action. Pardon me, but your mail have a very "corporate tone", if you
know what I mean... If you are not interested, don't read it... but
please don't tell others to be quiet...

IMHO, there are tons of small things that needs to be done. And a lot
of that can be done without much code changes. My "user perspective"
is perhaps only one of many (incorporate Jini technology into another
open source project), but from where I am coming from Jini 2.x is hard
to use, especially compared to maybe another 100 or so open source
projects that I have crossed path with in a similar fashion. I happen
to think he reason being that Jini comes from a corporate environment,
which delivers software in a certain fashion. I also think that by
stirring up the soup, I can create an "open development" evironment
where things are less homogenous, has flaws here and there so itches
can be scratched without breaking everything.

Too bad you won't engage in discussions, but that is your right.


Cheers
Niclas