Whilst I think that resisting the urge to over architect an idea or change to the point where nothing is actually moved forward is a good move, I think it's also dangerous to continuously live in the here and now with regards to changes as the platform and the specs do not evolve. Perhaps then, it may be more prudent to have two or three streams of workload; an Immediate list of bugs and common sense changes which will require little to no community discussion and another stream for issues and ideas that require more thought and debate, such as new features and spec changes. There may also be a third stream to deal with short to mid term Dev work or additions.
For instance, I've already mentioned about bolstering and refining the standard service implementations, but also I think work needs to be done on the standard service browser and adding ServiceUI into all supplied services. Also I'd like to see some focus made on HtmlUI interface/impl given the general uptake of web libraries like jQuery to provide more interactive experiences through web browser. Looking further forward (3.0) we could potentially look at, for instance, things like Executors in spaces, optional services, enhancements to the Reference implementations, integration with other frameworks such as Spring and/or OSGi, IDE tooling, etc and the old one of comparative Entries. I think that a key concern has to be to take a look at the things that were seen as key to Jini / River moving forward such as the surrogate architecture and decide whether they are now relevant and if they are whether we need to refocus on what direction these developments should now take. But this is all just my opinion :) --Calum Sent from my iPhone On 13 Feb 2011, at 18:40, Greg Trasuk <tras...@stratuscom.com> wrote: > > On Sat, 2011-02-12 at 06:03, Peter Firmstone wrote: >> ... > >> have to discard incompatible registrars and try again. It would be >> pretty easy to set different groups for different Java OS versions etc. >> It's an interesting road...the potential is here, but I get the feeling >> people just want to focus on the particular platform they're interested >> in at the moment. >> > > For me it's more of an urge to resist architectural astronautics. Solve > problems that we actually have now. If someone were to come forward and > say "I'd love to adopt River, but I need feature 'x', and then a few > other people were to come forward and say "you know, that's a great > idea, and it would let me do '[y, z, a , ...]" then we have a something > to look at. > > Of course, there's no problem with an individual exploring a cool idea; > just please do it as an 'extra' and not in the core until we all know > it's something we want to support as a community. > > As an aside, that was the idea behind the old Jini Community Process: > develop services and/or features to you heart's content. If you believe > your thing has wide applicability, then present it to the community. > Since you've already developed it and probably used it in the real > world, it will be free of the architectural astronautics that an "Expert > Committee" would have been subject to if they developed it from scratch > (SOAP/WS-* anyone?). > > Cheers, > > Greg. > -- > Greg Trasuk, President > StratusCom Manufacturing Systems Inc. - We use information technology to > solve business problems on your plant floor. > http://stratuscom.com >
