I'm not sure how feasible that is at the moment since the site's features aren't stable enough to have a stable API. Perhaps in the future.

Re bandwidth concerns, most of the data you receive from the site is cached so you only have to download when it updates. Once connected to a game we're using websockets to exchange data, so it's a very small amount of traffic, on par with native clients when you're playing live games. For correspondence play you're looking at having to load each game up in turn, so this takes a bit more bandwidth - about 15KB per page, so playing 4 moves is about the same amount of traffic as loading up a random image of a cat on the internet.

He's referring to the serverside browser mentioned previously, not to nova itself.

Exactly. I guess the amount of data once the game is loaded is negligible (I assume just the data to manage the game area so close to 0 with today's speeds), but a remote browser has to send at the very least 1 image per change, not sure how optimised the other side may be (it can be 30 frames/second or 1 frame for every n-pixels changed in the virtual screen.)

@skydyr, the API can be hooked a a middle layer GTP API. So, a generic GTP API is implemented and more or less fixed to the outside. When the inner Nova API changes, the GTP API changes how it connects to the Nova API, the GTP API doesn't change to the exterior. It's not like Nova can't do currently what GTP asks for.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

The map / graph for the open challenges is a neat feature in my opinion and a way to integrate slow and fast play is very much necessary when the time limits start with seconds and goes up to days. Imagine having only a list, which isn't necessarily sorted by time limit, where dozens of correspondence game requests make it hard to select a live game challenge.

There are features from OGS, that I miss on "nova OGS", however. Reviews are owned, which is probably a good way for teaching but the typical collective review featured on OGS is just not possible. Also, old reviews from OGS seem to be lost, unlike the old game records. Other than that, it already is working quite well.

I haven't checked myself, but I read somewhere that old reviews do not show up as "Review" but the comments are actually inside the game itself, so they are not really lost.

Yep exactly

Ahh, yeah that's kind of wild, and agreed, seems like a whole lot of bandwidth for something like this I didn't even know such things existed.. sorry for the confusion

Don't worry, no problem. But think about GTP

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

GTP is not suitable for writing a client, AFAIK. It is meant to connect go engines only and has no provisions for such things as kibitz, chat, observing games, etc.

Would allow playing in any case. Good enough I think...

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Also, no way to get a listing of open games, no way to join an open game, no way to negotiate time settings, no way to refuse an opponent.

With GTP, you can only act exactly like a bot: create an open game at your desired time settings, accept any opponent, never chat.

They could implement IGS-compatible commands. There are many ways this can be solved, worked around or prevented, even improved.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Yeah, they could create a proper API. I'm just saying GTP would not be a useful choice for creating a client.

The other big thing, for anyone having known OGS, is the current state of the tournament tables. Lists are not a good substitute for tables, much less compressed and harder to parse than an actual tournament table, there are some advantages of seeing all rounds at once, but you don't see how the tournament is going anymore. Tournament play was after all the main advantage of OGS over any other server I know. So, I guess this will be one of the issues that needs to be addressed to retain the OGS player base.

Played my first "live" game just now (actually a correspondence game where it turned out my opponent was online and we finished the whole game in an hour). Worked very well, good job

Lots of posts about ios browsing, what about Android? My experience so far is that, on Android 4.2, Chrome works fine, but Dolphin (my preferred browser) shows games but won't allow me to make moves (nothing happens on the GUI, and I keep getting server connection errors). Have not yet tried other browsers.

Shoot.. Dolphin used to work just fine, seems something has changed. We'll look into it after we've got some of these other bugs n features squashed. Thanks for letting us know!

Re GTP support:

We are planning on writing a GTP wrapper to interface with the system, but as others have pointed out, this is much more suited for supporting bots, which is what our interface will be tailored for. I suppose it'd be possible to have a human behind the wheel, but without some additional stuff for at least creating and accepting challenges, it'd be pretty difficult to make use of practically speaking.

We are working a more full fledged API to interface with the system from other clients, but it has to be able to support all of the various 'things' our site does (interface with tournaments, groups, chat, profiles, libraries, etc..), so it'll be a bit more complicated.

Just don't over-engineer the API. Remember that at its core a go server is a place to play go, so you need a perfect API that can manage current games in need of a move and sending and receiving moves. Adding comments to moves to interact with your rival is nice, but not fundamental for the experience of playing go. Same goes for everything else API related, having a perfectly defined core makes everything else easier.

Also, why don't you just use JSON as your api responses? From what I could tell from game_view-en.1.18-104-g3c9a4e9.min.js most pieces of the rendering are after all JS objects you are returning server-side (it's hard to tell completely, reading minified JS is a little tricky even with unminifiers.) If this is truly the case, JSON works perfectly as the messaging system, and you only need (kind of) to give neat API names to most of the current functions used in the browser view.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net