You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2016/06/30 03:37:55 UTC

Lotj - languages other than java

Currently with River, you need java to participate.  Other languages can provide services, but you need a jvm to participate.

Most of discovery is language agnostic, so any language can participate in discovery.

The major limitation for other languages is the lookup service.  Security issues and complexity also relate to the lookup service.

My thoughts are that a lookup service that performs search and registration, but provides a language independent  and secure means of contacting service providers would be beneficial.  

Anyone interested in discussing further?

Regards,

Peter.


Sent from my Samsung device.
 

Re: Lotj - languages other than java

Posted by Simon IJskes - QCG <si...@qcg.nl>.
If you solve the 'barrier' of the service discovery, do you also want to 
provide universal access to the java services in the form of microservices?

It is doable to take any 'more used' service discovery solution and use 
this as the river discovery. To introduce a level of abstraction with 
the same primitives as the current river discovery mechanism offers.

River would then have adapted a more common discovery mechanism.

Next thing that we should decide, is how far do we go into universality. 
I see univeral type systems, different serialisation plugins on the horizon.

The biggest showstopper for me was the API compatibility. In order to 
make any progress we need a more agile process for modifing the API.

If we leave compatibility behind us, we could ask our selfs, what 
benefit are we providing for the users? What can we introduce that does 
not duplicate what is already in the market. For a java developer, i 
think there is no need to convince, they can see benefits in just having 
a java API to program against. We need to think about the environment 
where java receives a lot of 'non-love', how we can create a 'whow, java 
isn't all that bad, look at that easy solution' experience.

I think that river lost the spot it could have, as a java only solution 
to JSON, XMLRPC, SOAP, etc libraries for java. From a helicopter view, 
what does it do? Whe provide secure RPC, with discovery and scaling. And 
we make it hard to use.

G. Simon


On 30-06-16 05:37, Peter wrote:
> Currently with River, you need java to participate.  Other languages can provide services, but you need a jvm to participate.
>
> Most of discovery is language agnostic, so any language can participate in discovery.
>
> The major limitation for other languages is the lookup service.  Security issues and complexity also relate to the lookup service.
>
> My thoughts are that a lookup service that performs search and registration, but provides a language independent  and secure means of contacting service providers would be beneficial.
>
> Anyone interested in discussing further?
>
> Regards,
>
> Peter.
>
>
> Sent from my Samsung device.
>
>