Add new gateway node-type

[JitpanuM]

Add new gateway node-type for transforming an api type comming to VILLASnode http server.
Currently it only support transformation of http and gRPC.
The protobuf payload that is not VILLASnode is also support using gRPC server reflection.
The gRPC server reflection feature is not available when install gRPC with package manager.
The additonal script is made to get the reflection.proto file from gRPC repo.

[stv0g]

@JitpanuM Please let me know, once this is ready for review.

So far the pre-commit CI check is still failing.
The failing arx packaging job can be ignored, as its caused by a different change.

[al3xa23]

Ready for review now :)

[al3xa23]

Hi @stv0g , the CI is building now. Can you make the review? What is missing from your side?
Thanks :)

[stv0g]

@al3xa23@JitpanuM Thanks for these contributions. I think its a really great addition :-)

I will do a review in the coming days.

I am wondering: Instead of adding a new node-type, cant we rebrand this node-type as v2 of the api node-type? To my knowledge it was never really used and has currently no active users.

I would like to deprecate the older v1 api node-type. Here your new node-type could be a nice update adding some more useful features..

Also, I believe api is still a better name for the node-type than gateway.

Or has there been some reasoning why gateway was chosen as a name?

[al3xa23]

Hi @stv0g, we chose originally gateway because we want to support different API conversions/translations. However, if you think, it makes more sense to have it in one API node-type, we can change it of couse.

[stv0g]

Hi @al3xa23@JitpanuM,

I think it makes sense to just name it "api". As far as I understand, we are not talking about a standardized API here. Its rather a custom VILLASnode API available over some network transports (HTTP, gRPC, ...).

For the existing node-type, its also the case. It was a failed attempt at creating a unfied API in the ERIGrid project.

So I would like to get rid of this node-type to reduce the maintenance burden.

As long as all these transport share the same foundation (methods, datatypes, ...) we should aggregate them in the same node-type.

However, we also support other APIs like NGSI via the ngsi node-type.
In this case its a standardized API, which should deserve its own node-type as its using different methods, data-types etc..

Going forward, I propose:

• Step 1: We create and merge a PR to remove the old api node-type
• Step 2: You rename the node-type in this PR to api
• Step 3: We rebase and merge this PR

What do you think? I am interested in your ideas too :)

[al3xa23]

Hi, sounds reasonable to me. We can do it like this :)