Create a deepstream.io client for .NET

[deepstreamio]

Create a deepstream.io client for .NET

[yasserf]

@NathanFlurry what we currently working on is a c++ libdeepstream library that will allow multiple other libraries to include it as a dependency using swig.

We already proved this works using python, but are simplifying the API considerable before expanding. What this means however is you'll be able to implement a deepstream library by creating a thin wrapper that only needs to:

• provides a websocket handler
• a timeout handler
• a public api that can serialize/deserialize data

[schulz3000]

Basic Version of my DotNet Client for deepstream is available here: https://github.com/schulz3000/deepstreamNet

Contributions are welcome :)

[nishant-newton]

Do we have any update for .NET client?

[kgodara]

Hey, I don't know exactly where progress with this is or how much has been completed, but I'd love to work on this if possible.

[grendo]

I took the github project down as it was based on a old version of the java client and. I am playing around trying to fully automate the conversion from java to .net so the client does not become out of date, (when I get time so no eta). I have managed to remove the dependency on google gson and the java websocket library, (for json.net and websocket4net). The last library I want to remove is ikvm as the author is not maintaining it any more. Then there is the cucumber testing to make sure things are working. Other options are https://github.com/schulz3000/deepstreamNet which I am not sure is still under development or taking the deepstream c lib with swig to generate a .net binding, (which will probably be the best solution). When I have the automatic conversion done I will put a project back up as it will be able to be maintained then.

In the mean time here is what I have. I don't think it is any long term solution but is kind of working, (note rename the file to .zip).

SharpStream.zip.pdf

[james-andrewsmith]

I've built a basic wrapper for the deepstream.io-client-js library using Edge.js to bridge between node and .NET. Check it out here: deepstream.io-client-net

My needs are really basic (only need login, emit, subscribe), but it's working well and I haven't had too many major headaches, unlike the other .NET clients I tried which seemed to have weird timeout and heartbeat issues.

Until someone can dedicate more time to wrapping the C client or building a protocol implementation from scratch it might be a useful option.

[schulz3000]

Hi,
I'm interested in creating a client for .NET
At the moment it was possible for me to connect, authenticate and subscribe to events with dotnet.
Will need some days to clean the code little bit up then I will publish a new repo with my try.

[yasserf]

Sounds awesome, looking forward to seeing it!

[WolframHempel]

I think the character codes for the split chars are a bit off. Its

exports.MESSAGE_SEPERATOR = String.fromCharCode( 30 ); // ASCII Record Seperator 1E
exports.MESSAGE_PART_SEPERATOR = String.fromCharCode( 31 ); // ASCII Unit Separator 1F

[yasserf]

Nice!

Have you ever come across http://www.specflow.org/? It's apparently the cucumber equiv for .Net and that way you can use the same test suite as the js client

[schulz3000]

@yasserf heard about it but never worked with it before.
For now I added a special branch with it but it looks like that there are some problems with feature definitions because duplicated scenarios.

[yasserf]

The main work involved is via specifying a mock server which simulates deepstream. The individual steps themselves should just be proxies from the cucumber scenario to the actual API.

I didn't know duplicated scenarios fail in certain languages! That would certainly be a problem. Would it be okay if you dump the error message in here and I'll do some digging into how to rectify it? I would also be happy if you tell me how to run them.

[schulz3000]

@yasserf created an issue for it in the specs repo to split it from this issue, because it's a little bit of topic.
deepstreamIO/deepstream.io-client-specs#3

[WolframHempel]

@kgodara that'd be great. We're not .NET experts ourselves, but happy to help out as much as possible

[schulz3000]

Hi @kgodara,
the basics are working in my dotNet client for deepstream.io
If you want you can get in touch with it and implement the new methods "has" and "snapshot" for records, implement a better error handling or create some unit tests.

[kgodara]

Hi @schulz3000
your client looks great, I'll look into the "has" and "snapshot" methods for records and work on implementing them soon, though I still need to familiarize myself with deepstream.io more.

[NathanFlurry]

After a lot of tweaking and messing with a lot of libraries, I finally got the Deepstream Java client transpiling to C# using Sharpen, which seems to be the most up-to-date transpiler. Here's some quick notes I jotted down when trying to get it to work; it's a really hacky approach right now, but I'm sure it could be improved:

1. Get Sharpen
   • Clone the source
   • Make sure using Java v7
   • Tried compiling using command line, didn't work well (see here)
   • Works like a charm in IntellJ
     • Maven clean & install (using the sidebar GUI)
     • Jar will be in /src/target
2. In Java
   • Delete test and application_test files; those don't compile
   • Move all dependencies into local package, since Sharpen doesn't play well with Gradle
     • Go to the Gradle cache, find <library-name>-sources.jar
     • Convert to .zip and decompress
     • Copy all .java contents into new package under io package
     • Adjust import statements accordingly
3. Execute Sharpen
   • Search the folder for "sharpen.properties" to find all the options for compiling
     • Will need to create a mapping for namespaces, types, etc.
   • Execute java -jar sharpencore-0.0.1-SNAPSHOT-jar-with-dependencies.jar <java project root> <the parameters>
   • Outputted files will be located in <enclosing folder>.Net folder

With some tweaking, I believe this could save a lot of time. Another option I didn't get around to trying was compiling the Java library to a dll, but I don't know how well that works. That said, @schulz3000's implementation looks very nice and is far nicer than this approach, since it utilizes C#'s async features.

[YanDevDe]

It would be also nice to add C# support - but it would be nice, if this would run also on MacOS, Linux, Android/iOS too. Thanks to Unity and/or Xamarin. Because I don't think so that .NET would run on other OS?
Anyways, I'm highly interested at C# support. Maybe I can help. Let see. :)

[YanDevDe]

@WolframHempel maybe you want to update the link from start post. All the link isn't working anymore.

[grendo]

I managed to get the java client client converted using ikvm/syntax converter. It works ok.

To do it I did the following

• used ikvm to convert google gson to a .net dll
• converted the java client code using a java to c# converter
• create a set of wrapper classes for all the generic dictionaries/lists, (as Java's Generics is so crap compared to .net)
• compiled it all up in to a project. I had to reference the ikvm libs to get all the java api's

The process could be automated potentially.
If I was going to take it further I would rip out gson for json.net as a start.

It might be a good start where you can refactor to make it a more .net native .net lib and remove the references to ikvm/gson.

[yasserf]

@grendo can you please provide a link? sounds pretty sweet

[superzadeh]

@grendo that sounds very interesting indeed. The main improvement would be to target the .NET Standard to allow as much portability as possible for the client.

[grendo]

I will get something together with the steps I followed. I did notice that on https://deepstream.io/install/ it says coming soon for .net so I are deepstream working on a client ?

there is also the https://github.com/schulz3000/deepstreamNet develop branch I have been playing with which seem like a good base, (instead of porting java)..

[grendo]

here is my port, it is kind of working. I have not updated for a few months so it was based on the java client back then. Would be good if the deepstream team let us know if they are working on a .net client or it is a community effort as there is not much point going further if a client is coming.

https://github.com/grendo/SharpStream

It takes about 3-4 hours, (with resharper help), to port and could potentially be automated and verified by the specflow tests.

With some more work you could automate the conversion, remove IKVM and Gson and any other java api's to replacing with json.net, .net api's to get a native client.

I don't have much time to maintain so take it as a proof of concept. There are a lot of hacks I did in the custom folder to get it to compile without changing the converted java code too much.

It might just be a good reference for https://github.com/schulz3000/deepstreamNet to help implement things.

[abmv]

@WolframHempel

Your first three links in the first post are not valid and going to Page not found. Please fix.

[EnglishAdam]

@WolframHempel @abmv

Here are the re-linked hyperlinks mentioned in the first post:

• Writing A Deepstream Client
• Deepstream Message Structure Overview
• Connectivity Spec to use against Cucumber
• NodeJS Reference Client

[yasserf]

@schulz3000 hey! We tried out your client and it works great, was wondering if we can have a quick call to discuss us documenting and helping support it? You can reach me at [email protected]. Thanks!

[YanDevDe]

Any update of this? :)

[yasserf]

None that I know of =(, we are hoping to base our work ontop of the large effort done by @schulz3000, just want to get confirmation first before we start anything

[NimzyMaina]

Just a quick question. Will this client be compatible with dotnet core?

[YanDevDe]

I guess the license cleary said "MIT" from https://github.com/schulz3000/deepstreamNet/blob/develop/LICENSE
so I guess he is fine with that. :)

[yasserf]

I'm closing this issue since the messages within it are outdated to V3 and Text Protocol, and would probably just confuse anyone starting to look into it.

The goal is to write a client in C or C++ around the protobuf protocol and then get other clients to just call into that.