Ωedit architecture proposals

[scholarsmate]

We are currently exploring 2 different architectures to support end-user applications like VSCode plugins.

1. The first one is our original design using Java language bindings and implementing a Scala HTTP server.

2. The second one is an updated design using Google RPC (gRPC).

The gRPC approach is currently experimental and is being researched in the grpc branch.

[shanedell]

From testing bindings with Java. I was able to create bindings to the shared library using SWIG to generate the Java wrappers, got it packaged and deployed using maven. However, I tried making a Scala project that would import this shared library and run into constant issues trying to activate library from the example from project or being able to access methods from the Java wrapper classes. Thinking this is because the Java methods are all static, which can't be accessed from non-static method and Scala doesn't have Scala. So it seems like there will be more work to be able to get Java working.

So we have bindings working in node however it doesn't support callbacks. This is why we wanted to do Java as it would do callbacks in a different (not so great) way. But my vote is that for the amount of time it would take to get the Java bindings working it would be better used to get gRPC going.

Furthermore, I think gRPC is the best way to go. Worse comes to worse I think if we absolutely want bindings to be supported in a language that will support a callback like functionality we try a different lanugage/

[jw3]

Here is a working example of an Omega Edit websocket server with Scala that demonstrates callbacks using jnr-ffi.

https://github.com/jw3/example-omega-jvm/blob/master/src/main/scala/examples/WebSocket.scala

Depending on the design of such a server you wouldn't have to have them.

[shanedell]

So yeah the way you have implemented would be a good example of how to have it work in Scala as you seem to have converted some of the C++ code into Scala. If this is the way we want to do things that is fine but the issue I was seeing was because of the SWIG generated wrapper Java code converting C++ that used a Shared Library. I think the Shared Library is a bad idea unless the code is converted into the language we want to use for the backend or hand write all of our own wrapper code in Scala.

[jw3]

you seem to have converted some of the C++ code into Scala.

That example uses the .so produced by the Omega build. It is a little dated, but not changed in any way.

I didn't convert anything, no tricks, just jnr-ffi providing runtime bindings to Omega.

https://github.com/jnr/jnr-ffi

[shanedell]

Oh okay. So what I was referring to was taking the SWIG generated Java code, compiling the classes and putting them in a JAR with the libomega_edit file, this would elminate the need for a class like OmegaFFI. However, this causes issues as Scala could not properly get the code imported and make use of it, do you think it would be best to just hand make the Wrappers similar to how you did in your example? So it will still use the Shared Library but we make the Scala classes that will wrap around and call the library, instead of trying to use SWIG wrappers?

[scholarsmate]

Implementing the gRPC server in C++ and then maintaining it has been and will continue to be a challenge. Instead, we've converged on using Scala to implement the server, which will be attractive to other potential contributors and maintainers. The existing C++ gRPC server and client will continue to exist as a reference implementation, which will be useful as a reference as we create the Scala server and JavaScript client.

[scholarsmate]

An implementation using the gRPC architecture with a Scala server is discussed (and shown) here #169.