Java version

[DaveSkender]

We're seeking Java contributors to contribute to an effort to build a version-synced parallel path Java package for this library.

If you or anyone is interested in contributing to this Java project, let us know.
We are currently building a baseline in a private repository but will make it public once a sufficient level of utility is achieved.

[97nitt]

@DaveSkender finally got around to looking into this. I've never attempted to write a Java wrapper around a C# library. And after a little research, I think I know why I've never seen it done. Requires some glue code, written in C++ in between. So you'd be maintaining, distributing, and installing 3 different libraries in 3 different languages. It's kinda gross. And it would come with performance costs too, running through 3 layers of software is likely to be significantly slower. I wouldn't recommend building a wrapper unless you really think it's necessary to do it that way.

Alternatives would be to:

• create a "port" of the C# library in each language you would like to support. Basically implement the same functionality in each language. This is pretty common, lots of client libraries have several versions that strive to provide the same functionality in multiple languages. Inevitably, one language is the vanguard, and all the rest lag behind.

• provide a language-agnostic interface, mostly likely HTTP (e.g. a REST or GraphQL API). This would require you to implement the HTTP interface around your C# library, and package the project so it can be deployed to a web server. In addition, you could provide a Docker image that would allow everything to be easily run in a virtualized environment. You could then host it on any cloud provider, or allow folks to run that image on whatever Docker-compatible infrastructure they want.

Happy to help out with any of these really. Even the wrapper, if that's what you decide you really want to do. I'd consider it one of those challenges you take on just to see if you can do it. But I do think you'd ultimately regret it.

[DaveSkender]

Well, for the Python wrapper, we're putting it in the main repo as it will version together once it's caught up. With that said, I can see some benefits of putting both the Java and Python variants in separate repos as I'm seeing this get a bit complicated. My only concern with separate repos is how to co-manage documentation.

[DaveSkender]

I think if we figure out how to cross-link the GitHub pages in a consistent way, we can maintain a sense of cohesiveness. Do you want me to create a new repo in my account, or do you think it's better in yours? It really depends on how closely related we'd want these to appear.

[97nitt]

Doesn't really matter to me either way. I don't feel like I need to "own" this repo, but if you're more comfortable with me owning it, that's fine too. Your call. GitHub allows you to transfer ownership of repos, so we can always change our minds later.

[DaveSkender]

I like your idea of one product that's available in different languages. If we stick to some basic common library design themes and get the documentation to sync and be consistent in style/branding, we can do that well. I'll create a repo and add you. If you change your mind and want to own it entirely separate, sounds like we have a way to do that.

[DaveSkender]

I've created it and kept it private for now, until we get the basic setup in place and are ready to take on more community contributors.