Extending applicability and utility of the c0apps.
Closed this issue · 4 comments
I wanted to suggest extending the m0tr demo apps in such a way that they could be extended and leveraged without necessarily runtime binding to m0tr or even "C" libraries.
For better or worse, most of the tool and utility world has moved on from C, C++, and even Python to "go". As you probably know, it is the foundation for most of Kubernetes, OpenDNS, etcd, MinIO, Prometheus, and nearly every interesting paradigm shift in the open source cluster world.
Creating golang binding to the m0tr interfaces demonstrated in the c0apps can be done, but it would take a couple of weeks to do and would probably reflect a layer of coupling to m0tr implementation details that I'd really rather not take on.
The stupidest, simplest thing that could possibly work is to leverage named pipes or some such as a data IPC conduit between the m0tr world and demo m0tr applications. This would render them language agnostic and enforce a line of demarcation that would allow m0tr to continue to improve independent of applications demonstrating and leveraging it.
If we refactored the c0apps to accept a named pipe to sink/source data streams, and where appropriate, render json informational inputs and outputs, it would be very easy to plumb in a prototypes of other use cases. If the prototypes demonstrate potential value, then the effort to develop an optimized interface could be invested.
I Agree @suykerbuyk. The current implementation of c0apps started as sample implementation to demonstrate Clovis (client) interface EU project partners. It still serves as source code examples to new comers to m0tr client interface. A go implementation was recently made available here:
https://github.com/Seagate/cortx-motr/tree/3c3921704f18544a181592aaab4cd7bffbc5b202/bindings/go
This provides a utility called mcp that reads/writes files to/from m0tr objects. Again, mcp is a simple demo utility but I have seen the power of it when we needed a utility to read/write to/from the Sage cluster using multiple threads.
Certainly we should explore go option more.
I believe this issue is resolved and can be closed. I will close now and it can be reopened if you would like to reopen it.
Chandradhar Raval commented in Jira Server:
Marking this Jira Closed based on above comment