For the record, I’m not proposing River lite, I’m just wondering about pruning features that are old and little-used. I think what I’d probably want to do is just split out the features into a separate library (for backwards compatibility), but if there was no great interest in it, I’d just drop the features.
As far as JSON, I’m wondering how River fits with JSON. As it stands now, you could certainly create a service proxy that uses JSON to talk to a service. That’s standard smart-proxy stuff. perhaps Gregg W can expand on what River/Jini brings to the picture that’s over and above any other method of accessing RESTful services in Java. Cheers, Greg Trasuk. On Feb 17, 2014, at 3:11 PM, Simon IJskes - QCG <si...@qcg.nl> wrote: > Simple, > > less decided than on removal of the JRMP. I've never used activation. I > wouldnt use it. > > What you are proposing is a river lite. RPC + registry + discovery. I believe > this is a good approach. JSON, i like the idea. Code mobility by external > means. Also good. > > Another experimental branch, i wouldnt support. I'm all for development on > trunk. Branches are for QA and patches. > > Gr. Simon > > On 17-02-14 15:01, Greg Trasuk wrote: >> >> Hi Simon: >> >> What are your thoughts on the Phoenix service and activation system? >> >> Cheers, >> >> Greg Trasuk >> >> On Feb 17, 2014, at 7:07 AM, Simon IJskes - QCG <si...@qcg.nl> wrote: >> >>> On 17-02-14 13:06, Simon IJskes - QCG wrote: >>>> On 15-02-14 19:45, Greg Trasuk wrote: >>>> >>>>> I wonder if we can just discuss the idea of removing activation and >>>>> JRMP support from trunk? >>>>> >>>>> For me, JRMP is a no-brainer - the functionality is much better >>>>> covered by JERI. I think JRMP was only there for backwards >>>>> compatibility to Jini 1.2 services. >>>> >>>> +1 >>>> >>>> >>> >>> Sorry. too quick. +1 on removing JRMP. >>> >>> -- >>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >> >
