(cc’d to user@ for discussion) Not sure about a research branch - I’d like to focus on making it easier for developers to use River in real applications, so I’m hesitant to do anything that diverts attention from that. On the other hand, we should perhaps try out some things. On yet another hand, I’m not sure if easier deployment is necessarily backwards-incompatible. I’d love to hear more opinions.
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. Activation is a little more difficult question. Personally I’ve never used it, and I suspect the rationale for it (maintaining service availability in restricted environments) is not so strong these days. We generally seem to be OK with leaving services running all the time - that’s the deployment model for XML- and REST-based SOA. So I’d be fine with just dropping support for JRMP and activation, but we should hear more opinions. Something I would like to see is a messaging-based channel for JERI. Something like JERI-over AMQP (i.e. using a QPID server). AMQP is gaining traction in the financial industry (it originally started out at JP Morgan Chase), but the challenge as with any messaging protocol is how to structure the messages. I’ve seen Google Protocol Buffers used, but that seems over-architected to me (and much like XML/SOAP, incurs a large development overhead to get platform neutrality that is seldom actually used). I think allowing for Jini would give the advantages of low configuration overhead, but still give the low latency that AMQP promises. That also seems to fit in well with a space-based architecture for load-balancing. Anyone else have thoughts on dropping JRMP and Activation, or on adding AMQP endpoints? Cheers, Greg Trasuk. On Feb 14, 2014, at 10:52 PM, Peter <j...@zeus.net.au> wrote: > Any takers for a research branch to exlpore recent ideas? > > Was thinking about a subset of Jini, just the essentials, no activation, no > JRMP support, forgetting backward compatibility to allow experimentation with > new ideas and considering all possibilities. > > Regards, > > Peter.
