> Sounds like it should be it's own (sub-)project. That's a good point.
>> Yes, I agree that the services do not use these utilities, but that's >> missing the point. In my view, these utilities should *not* be used >> by the services anyway. > Well, I disagree. What better way to enforce and test the use of utilities > than having River itself use them? Because (in my mind at least) these utilities lie in some kind of middle tier; where River is the lower tier, and the business-specific application stuff is the higher tier. These utilities make it easier - when going from high --> low. >> I agree again here, but again with a caveat. I would like to see a >> lot more chatter going on between as many of those external projects >> and River as possible. > > I'd suggest that this has already been happening. I'm here am I not? :) Fair point. > With all due respect I think you're missing the point. The issue here is that > many of the things that you wish to accomplish have most likely been done > across the myriad of Jini projects that have been out there for years. The > reason these projects have been created is "to make it easy and obvious to > application developers". Historically, the Jini community at large seems to > have a hard time recognizing and endorsing external projects, I dont know > why, it just has. What I am seeing here is an opportunity to leverage the > work that has been done to move River forward in a better way. I see your point, but let me mention my concern - then the community can let me know if that concern is valid or not. I'm prepared to believe that it's overstated, but not 100% convinced yet. Imagine you're someone evaluating an SOA for your green field project, you've heard of River so come to the site to find out more. I'm concerned (maybe that is to strong of a phrase) that if the entire River documentation consists of the Jini specs and a cookbook which says "To do this, download that project. To do something else, download a different project." then that's going to put people off taking up River. And I think it short-changes River, in that some of these things may come across as appearing that in order to do X, you actually need to download River AND project Y - when actually, you *could* do all of X just with River. Strangely, I don't have a (emotional?) problem with people coming from the opposite direction. They arrive at External River Project A, think that it looks good and then notice that they also have to download River as a dependency for that project. To me at least, and I'm happy to be told I'm being crazy, the above paragraph feels like it's going to drive new developers away from River, where as the beginning of this one feels like people adopting River - albeit "under the covers". I guess it depends on where in the application stack you consider River to be. If you consider that River *is* just the low level stuff and in order to do neat and interesting things with it then you need a third party application sitting on the top, then you're right. In which case, this whole "extras" thing is just extra work without any extra benefit; and we should probably consider abandoning it in favour of devoting time and effort to supplying extra River features which make those external projects better. However, if you consider that River can do neat and interesting things without a third party component (as I do) then the River site needs something (code or documentation or both) which shows that. If that means reproducing features that exist in other third party apps, I don't actually have a problem with that. It's not my goal to make those thirty party applications redundant. What is my goal is to make someone's life, who has no River/Jini background, easier by supplying a "bunch of stuff" that comes with their River download that enables them to do a quick (and maybe dirty) proof of concept for their managers. For me, one of the key parts of the previous sentence is "comes with their River download" - but maybe that's just me projecting my own laziness onto everyone else! :-) > Instead of going out and developing utilities, you could provide a list of > capabilities (perhaps creating a call for action), and those that would be > inclined to contribute can. > Alternatively, you may also be pointed to open source projects that allow you > to build upon (or leverage/learn) what has already been done. I have no pressing desire to write a ton of code when other people might be prepared to donate existing code which does the same thing. However, in the absence of a contribution, what other option is there? And I concede in advance that I've not made the details of these utilities clear or made any request for help - which is why I've not had any offers yet! I think the above question of "does River exist just to service third-party container, or can it be useful on it's own" really needs answering; because that's going to point us (and this discussion) in the right direction. What are your thoughts? I hope this email comes over as friendly (and questioning) - which is my intention. Rather than argumentative and defensive - which is not my intention. Cheers, Tom
