Robot Not a Dev? Pre-order Now
Not a Dev?

Roadmap for client libraries?



I suppose that after the release of the first non-developer edition of Misty robots, there will be some declaration about API versions, backwards compatibility etc. For example, this is motivated to prevent unexpected breaks of apps developed by and sold by third parties.

In turn, there will be client libraries that wrap API access in various languages.

Because of the potentially very large number of such client libraries, keeping all of them in one repo that is maintained by the Misty Robotics company does not seem sustainable. However, developers will likely use the Misty Robotics website as a starting point to find client libraries, so some centralization is motivated.

So, my question: what are your plans for API versioning and management of officially supported client libraries?

If the plan is still in development, this topic can be a place for discussion. As some motivation, the current approach seems to be collecting of API wrappers in the subdirectory MistyI/API_Wrappers at master · MistyCommunity/MistyI · GitHub The Python client library, which was first released at GitHub - cameron-gq/mistypython: Python wrapper for Misty REST API was recently copied there. Until several hours ago when Cameron posted a note about the repo moving to MistyI/API_Wrappers at master · MistyCommunity/MistyI · GitHub, there was ambiguity about which one was current, and where issues should be posted, pull requests sent, etc. Earlier, I opened an issue at what I now have discovered as the wrong repo: port to Python 3? · Issue #1 · cameron-gq/mistypython · GitHub


The problem of maintaining many client libraries is common for any company that provides an API (HTTP-based or otherwise). I think the general solution is to have officially supported client libraries and then a big list of ‚Äúcommunity-maintained‚ÄĚ libraries, with links to the respective repositories.

A successful example of this method: Stripe: API Libraries


This is as great discussion topic. And while the days of non-developer Misty Robots is years away, we can always start thinking of this.

@brad and @CHRIS_IS_MISTICAL may have some experiences a d thoughts about this.


Hey @slivingston, those are great questions, and you are right that a lot of this is still in discussion, including improvements to our api and api library versioning and backward compatibility plans. We are doing our best to ensure that we minimize the impact on developers as we continue to improve the api and the robot.

I agree that there should be a clear separation between Misty’s and other’s products and libraries, but I would think we should be able to provide some reference to other libraries. I think the Stripe link you provided does a good job of that.

Thanks for bringing up this topic.