[Suggestion] Use platform & language neutral server/client bidirectional architecture

[anzellai]

@murilopolese - looking at your other 2 issues here and there.
You're running into the complication of programming specific issues -- like dealing with Python thread
out of main function, and direct port of NodeJS / Python websocket implementation on language level.

Here's my suggestion to use a platform-neutral and programming language-neutral solution:

• gRPC is a platform-neutral and programming language-neutral mechanism;
• gRPC communication, using definition file, we can generate both server/client language specific library;
• it can be much faster than http/2 with JSON, some benchmark from etcd;
• you're already using RPC;

Rather than giving you a solution on your issues, I have created a simple Proof of Concept to demonstrate how this can work and potentially eliminate a lot of similar issues you might have in future.

Let's dicuss :-)

[murilopolese]

Hey, @anzellai ! Wow! That is a fantastic work you have done there! You definitely demonstrated you are technically capable, thanks for that. On the other side, as yourself mentioned, this suggestion doesn't solve the issues that are opened.

I read the suggestion made here as solution to a problem that is not clearly related to the current issues nor this project's main goals (defined together with stakeholders and the people who might actually use this SDK):

• It doesn't make the SDKs easier to understand: It actually requires a much more advanced skillset for a user to read and understand what's under the hood.
• It doesn't make the SDK easier to use: You will need to install even more than the "client" to use
• It's not a smoother transition between Kano Code and user's choice of programming language
• It looks more like a performance oriented solution which is very much out of the scope here

It's ok if you don't agree but I would suggest you to evaluate what are your assumptions of what this project should be and what's stated on the README.md:

• https://github.com/KanoComputing/community-sdk#what-is-the-community-sdk
• https://github.com/KanoComputing/community-sdk#what-are-those-sdks-for

I'd like to invite you to use your clearly advanced skills to push together in the same direction instead of trying to steer this entire project to a different place ;P

Therefore, I'm closing this issue in the hope you will open 10 others, more relevant to where I hope this project is going. :)

[anzellai]

I have no objection you are closing this “suggestion”, however I do think you have missed an important point I’m trying to argue — you want your community sdk as portable as possible, which in my humble 20 years experience working in both hardware & software makes me believe you need a portable lib as an abstraction to steer all the difficulties/complication behind the scene and let your users explore the full power of the Kano kits in a simple and easy to understand manner, which your SDK currently isn’t doing that.

I also think you have missed my POC of the server implementation — as a user you don’t need to compile/create the server, when we create the sdk for client, we can have an Init wrapper to call directly the embedded server code (spawn a child, run in different processes whatever) and connect to it, returning the connection handle to the client — which in my POC, they just need to call “Communicate”, then “Send” or “Recv”.

Generally speaking, your point is valid if we’re talking about an abstraction over a set of functions/classes/communication protocol — like RESTful APIs etc., but this is very different in hardware sdk, which apart from comms protocol you also need to deal with manufacturer’s settings/config.

Usually company ships with platform specific library (like Windows’ dll, *nix’s so/dylib), alongside their sdk. And you’re missing exactly that. A portable library for serial communication... hence you need to have different dependencies on each programming language, and since each programming language has its own semantic/coding paradigm, you end up porting your “base” Node/JavaScript into fixated style and fighting against language’s limitation/complication.

Look around NXP sdk, which I believe is one of the mostly used hardware sdks for serial comms for their RS232/485 products, they ship with a c/c++ base lib and use FFI strategy for people to interact with their manufactured devices.

10-20 years on this pattern still holds, and I really recommend you consider this strategy, the lib can be C lower level comms abstraction, or like mine with portable lib to communicate with your programming choice in either RPC/REST or callbacks strategy.

Just my 2 cents, and please still feel free to ignore and go your way — this is your project after all :-)

But I fear that I wouldn’t be of much help to contribute to your SDK as we have clearly different opinions on this and I don’t want myself to keep fight your good contribution spirit, I hope that makes sense.

[murilopolese]

Once again, @anzellai : Your suggestion is not wrong or bad, it's only out of place. I think what you want is to swap the current serial modules/libraries and if so, go for it: But make a full proposal with something that is ready to be swapped because developing/discussing a low level abstraction for serial communication is not the goal of this project.

I do think you have missed an important point

I don't think so. I understand your point but perhaps you are missing a few more important points here: that is why I'm repetitively writing the same things in the hope to convert you to a contributor :)

you want your community sdk as portable as possible

No, I don't. Although I never mentioned this, I think the "portability" aimed by this project is different than the "portable" you mention.

let your users explore the full power of the Kano kits in a simple and easy to understand manner, which your SDK currently isn’t doing that

Why exactly not?

this is your project after all :-)

Just to be clear: I'm the intermediary between a few stakeholders, contributors and users inside and outside the company: Customer care, marketing, product, EDU, teachers, etc. This is "my project" only in the sense I started it and I'm trying to make sure this get done in a way that benefit most parts. It can be yours if you want to join.

we have clearly different opinions on this

So we agree to disagree? I made the effort to read carefully all you wrote, empathized with your suggestion and tried to answer you with all the respect you deserve. But if comes down to disagreeing not with me but with this project's goals, then that is it. You are welcome back any time and I encourage you to do so :)