From what I understand, development on the OGS android app is on hold - matburt and anoek have their hands full with the site, and need some time off to see their families and sleep[1].
It strikes me that we’re a pretty technical bunch, and since we have an open API, why not build some open API clients? I keep intending to start up either an Android or IOS client, but can’t seem to get motivated by myself.
So I’m suggesting that we set up a Github organisation for OGS-mobile, and open-source the world’s best go clients to play on the world’s best go server.
If you’re interested in getting involved, drop a comment below and we’ll see what skills we have available here on the forums.
Do we write Obj-C and Java individually, or go HTML5 hybrid app? do we write the whole thing in Xamarin Mono?
– Bob.
[1] They don’t get to eat though. They just synthesise energy from the cold radiation of their monitors.
Sadly im not enough of a programmer to help with the code since all i know is a little bit of python, but im happy to help in any testing, suggesting, translation or whatever else there might be that i can.
I think a solid app for ogs is going to go a long way to promote OGS. I think its important for a corr-game-platform to have a solid mobile application. !
I’m strongly considering a c++ core for networking and data, that means it can use gnugo or fuego to do score estimation, sgf reading etc. If we go with HTML5 for the ui, we could start by grabbing glift.
@matburt if we eventually wanted real-time for live games, what’s the protocol we need to support on the client? I’m guessing it’s some kind of websocket magic. I’m only asking because it might affect choice of frameworks.
Based on the conversation in the thread linked below, it seems like the devs do not want to release the details of the interface to the general public. An open-source project using that interface would essentially do that though.
I am assuming by matburt’s participation in this thread that he is giving tacit approval for this…
I would love to pitch in and help where I could (C++/C#/Java) but I don’t know much about network protocols or HTML5. Also, I probably won’t have bandwidth to help with the project until late September.
I guess what helps in this case is that we’d be able to see the code and that makes me feel a lot better. It is important that we be able to trust that the project will properly conceal the private keys that will be used to authenticate with the service.
I’d like to see some work done with the basic rest api first as a good starting point, though.
Is it possible for an open-source project to use private keys without disclosing them? Maybe I am misunderstanding something about how authentication works.
Yes, I’ve done this with several projects that needed to interface with things like Dropbox and whatnot. (They also require you to keep these keys secret).
Namely you just have to make sure you don’t check these keys into source control.
Okay, so it is still “open source” because the source is available, but an anonymous user can not clone the repo and test it out because he will not have the keys to talk to the server?
They would just need their own keys and wouldn’t/shouldn’t use the production keys. This actually goes for the REST api keys also. It’s just good policy to not give out your own keys.
We perform throttling based on the user making the request AND the oauth2 client making the requests and If someone took your key and started making malicious requests against the server we would ban/block that key from being used. If it’s the same one that you use for your production application with lots of users they are going to be pretty unhappy.
Websockets do support CORS stuff. Wouldn’t adding more domains to Access-Control-Allow-Origin header allow for easier access control without having to gamble with private keys?
// edit: well, i suppose it wouldn’t actually restrict communication at all, just prevent some cross site scripting from other domains. Forget about it
I’m doing a bunch of prototypes to see how various frameworks fit together. I’m currently thinking about building the whole thing in C++using Marmalade SDK. What kind of development experience do you have @royjac ?
Android is target #1, followed by iOS, followed by win mobile, followed by … oh god, I dunno… Smart TV applications or something.
For those who are keeping track, I’ve done a few experiments and think Marmalade SDK will do everything I need it to do. I’ve hacked out a quick and dirty event-driven MVC framework, and I’m trying to cajole libcurl into playing ball.
Either I’ve got a build issue, or I’m an idiot - either is equally likely right now.
I did get board renderings working with json data, though, but I think I’m going to throw it away and re-do it in OpenGL because anti-aliasing.
Cue ugly screenshot with bounding boxes and ting, the game positions are real, the other data are lies.
