Topics

cavium go work

Drasko DRASKOVIC <drasko@...>
 

On Tue, Oct 10, 2017 at 2:51 PM, Fede <fclaramonte@...> wrote:

Two ways we can take:
1) We set-up an official repo and I upload the code, then we take it from
there
2) You send PRs to my repo for now, as Tyler already did:
https://github.com/drasko/edgex-export/pull/1
Any of both options are fine with us. Maybe the second is best until it is
completed and can be moved to an official repo.
Great, please send PRs.


I was also asking about what can we work on, like helping you with
distro(how) or start implementing some of the missing microservices.
I am only only maintaining Export services for now, as Dell is working
on Core. Once Dell opens the Core we can start working on this,
probably Jim can give us more insight on this.

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.

Apart from Export services, I think other interesting field are Device
services. This way once Dell opens up the Core we will have whole
vertical. I would propose that we all begin with Export services
though, in order to establish best practices and agree on
technologies, packages and patterns, and later switch to other
services applying the same code style.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Fede Claramonte
 

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.
We have started to look to distro, but we had some questions:

- There isn't a go 'native' library to use zeromq. There are some go wrappers for the C library like https://github.com/pebbe/zmq4.  Do we will have some policy about c code in the go port? What library is being used in the core-data go port?

- The data sent with the zeromq messages is a serialized java object (https://github.com/edgexfoundry/core-data/blob/ed14690aeecf0498387dfd5d7755f6431941090a/src/main/java/org/edgexfoundry/messaging/impl/ZeroMQEventPublisherImpl.java#L92) What should we do? Try to deserialize the java object to be compatible with the java version? Using a different algorithm to serialize the objects (json, protobuf,...)?

Regards
Fede

Drasko DRASKOVIC <drasko@...>
 

On Wed, Oct 11, 2017 at 4:59 PM, Fede <fclaramonte@...> wrote:

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.
We have started to look to distro, but we had some questions:

- There isn't a go 'native' library to use zeromq. There are some go
wrappers for the C library like https://github.com/pebbe/zmq4. Do we will
have some policy about c code in the go port? What library is being used in
the core-data go port?
While we are there, may I propose switch to gRPC and protocol buffers
(https://grpc.io/) :)? Otherwise, I find nanomsg better approach then
ZMQ: https://github.com/go-mangos/mangos


- The data sent with the zeromq messages is a serialized java object
(https://github.com/edgexfoundry/core-data/blob/ed14690aeecf0498387dfd5d7755f6431941090a/src/main/java/org/edgexfoundry/messaging/impl/ZeroMQEventPublisherImpl.java#L92)
What should we do? Try to deserialize the java object to be compatible with
the java version? Using a different algorithm to serialize the objects
(json, protobuf,...)?
+1 for gRPC and protobuf. Performance matters, and gRPC is extremely
well supported in both Go and Java. There is much more than simple
socket connection patterns that comes with gRPC.

Otherwise, if we are sticking with ZMQ, maybe even JSON is not so bad,
for simplicity of implementation.

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Luca Capra
 

Dear,
I would suggest gRPC also, in m experience performs well and have good
support on many popular languages.

Regards
Luca

2017-10-11 17:26 GMT+02:00 Drasko DRASKOVIC <drasko@...>:

On Wed, Oct 11, 2017 at 4:59 PM, Fede <fclaramonte@...> wrote:

ExportDistribution microservice is priority - I practically did not
touch it yet. And since all needed Export Java classes will be ready,
you can
start on ExportDistribution right away.
We have started to look to distro, but we had some questions:

- There isn't a go 'native' library to use zeromq. There are some go
wrappers for the C library like https://github.com/pebbe/zmq4. Do we will
have some policy about c code in the go port? What library is being used in
the core-data go port?
While we are there, may I propose switch to gRPC and protocol buffers
(https://grpc.io/) :)? Otherwise, I find nanomsg better approach then
ZMQ: https://github.com/go-mangos/mangos


- The data sent with the zeromq messages is a serialized java object
(https://github.com/edgexfoundry/core-data/blob/ed14690aeecf0498387dfd5d7755f6431941090a/src/main/java/org/edgexfoundry/messaging/impl/ZeroMQEventPublisherImpl.java#L92)
What should we do? Try to deserialize the java object to be compatible with
the java version? Using a different algorithm to serialize the objects
(json, protobuf,...)?
+1 for gRPC and protobuf. Performance matters, and gRPC is extremely
well supported in both Go and Java. There is much more than simple
socket connection patterns that comes with gRPC.

Otherwise, if we are sticking with ZMQ, maybe even JSON is not so bad,
for simplicity of implementation.

BR,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Drasko DRASKOVIC <drasko@...>
 

On Wed, Oct 11, 2017 at 7:03 PM, Luca Capra <luca.capra@...> wrote:
Dear,
I would suggest gRPC also, in m experience performs well and have good
support on many popular languages.
I do not know yet very well how do we use ZMQ and what connection
patterns are needed. But if gRPC usage is not possible, my second
choice would be nanomsg over ZMQ, as I mentioned:
- http://nanomsg.org/index.html
- http://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/

Good support in Go: https://github.com/go-mangos/mangos and Java.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic