How are you supposed to implement a client that can play live games on OGS, if you can’t continually poll the game state from the server? I agree that polling the whole sgf several times per second is far from an ideal situation, but I don’t see any other way of doing it with the current API. As far as I know, the fact that the API is using HTTP means that no matter how you design it, the client will have to pull.
Or is the API simply not meant to support clients that can play live games?
Note that I am not actually trying to create a full client, so I don’t need this feature. Don’t drop anything you have in your hands to do something about this for my sake. I do however think that it is a pretty fundamental problem with the API if it is meant to support full clients.
We have a live game interface… this is how our own client interfaces with the game. However, we aren’t just going to give everyone access to this interface as-is right now.
I’d say 99% of api consumers don’t need access to real time move information and we will look at those 1% on a case-by-case basis. So while our rest api is public our real time interface is subject to a more strict approval process.
This is a little surprising to me. When I see a Go server with an API, I automatically assume that the main purpose of the API is to allow 3rd party programs to use to go server for its main purpose: Playing go. But fair enough.
I am wondering why you have chosen to restrict access to the real time interface? Are you afraid that people will blame you for shitty 3rd party clients?
It’s perfectly possible to use the api to make moves, read game state, whatnot.
I guess just because it is easy to do it badly and, yes, because we would like to make sure people use it in the right way. There are certain requirements we would like satisfied in that regard. If it’s something you are interested in then please feel free to contact us directly.