Dave makes a very good point - one that had completely passed me by despite me muttering "Why can't you google it yourself?" many times under my breath at other people!
I'm sure that those site's won't mind us linking back to them, I guess it's common courtesy to ask them first though? I don't know what the appropriate etiquette is though. (Where' C-3PO when I need him?) I can certainly do this bit. As for engaging users, I think that has to be a must. The user list is not hugely active; I kind of get the feeling that people accepted the Jini 2.1 code and have pretty much ignored River since. At least, that's my experience of "Jini vs River". We need to publicize River and get people downloading and using it. I've seen commit and download charts on other open source projects. Does anyone know how we can get those - or if they think it's a good idea? Drop Box have a good "vote for this feature" part on their website which users use to influence the direction of the service, which is a good idea. (I'd not really seen it before.) I think it needs an active user base to be useful though; which kind of puts us in a chicken/egg situation. On Mon, Nov 15, 2010 at 12:27 PM, Patricia Shanahan <[email protected]> wrote: > On 11/15/2010 4:08 AM, Dave butlerdi wrote: >> >> Why not provide some info on Sun's internal useage as well as the hundreds >> of projects that come up with a simple Google ? >> >> http://docs.sun.com/source/819-1696/RFID-intro.html for a start. >> >> http://giatsi.deetc.isel.pt/index.php/pt/recursos/doc_download/9-isibus--jini-and-radio-identification-technologies-underlying-interoperability-through-a-real-life >> http://gevaperry.typepad.com/main/javaspaces/ >> >> The list is long..... >> >> JINI has been incorporated in many projects and the only reason I can see >> that River has been slow is the seeming lack of direction and >> the intense emphasis placed on minor issues that do not affect useability >> (IMHO). > > ... > > I think we need contacts with users, not just to make a nice web page but to > get direction on what does matter to them. Solidity - the code works as > documented every time - is a good initial target. Fixing bugs that prevent > QA tests from running is a step in that direction. Beyond that, we need to > know where we are heading in the longer term. > > Although I made a stab at TaskManager performance improvement to get started > on River, I'm reluctant to do performance work without access to data from > real systems. How do I know whether my changes make River better or not? > > Is enhancing robustness to make River safer to use over the Internet a good > target? Or is there something else we should be doing that matters more to > users? > > Patricia > >
