KGS Status

    Keywords: Online Go, Clubs & Places, Software

This page is where wms gives info on the status of the next KGS release. It's kind of a companion page to the KGS Wishlist; the wish list is where KGS users say what they would like me to do, this is where I say what I want me to do. For slightly more long term plans, see KGS Plans. As soon as a release is out, I'll cut out its status from here, but you can see past release status at [ext] the KGS change log.

For information on whether the KGS server is down, see KGS server status.


2.6.12 is out.

I have started work on the next release. It may take a while, it is a fairly big change. For this change I am finally rewriting the server in Java. Over time I have been slowly refactoring the client to clean it up as things are added; as a result, the client code is quite nice and it is easy to add new things. Meanwhile, since the C server is so difficult to refactor, I have been just cramming new features into it wherever they seem to fit. The end result is that the server is a mess, very difficult to make changes to. Hopefully this rewrite of the server into java will let me keep its code quality to be similar to the client's.

Progress on 3.0.0

Don't expect huge changes in 3.0.0. It's mostly a rework of a lot of server code that has gotten crufty over time. The main benefit is that once the code has been cleaned up, a lot of changes that I've been holding off on will become possible.

  • Network code written.
  • New rank system is done. I'm moving it out to a separate application for a variety of reasons. It uses about half the memory of the current rank system (good, since the current rank system is the biggest memory hog on the server), but runs a bit slower than I was hoping. I'll decide later whether I care more about speed or clean code, for now keeping the code clean is more important to me.
  • User database done.
  • Archive channels done.
  • Room channels done.
  • View your user details & picture.
  • Room list done.
  • Private conversations done.
  • Message boxes done.
  • Buddy/censor/fan lists done.
  • Challenge code is done.
  • Can play a game through - clocks, scoring, etc. all works.
  • Games are saved to disk and persisted into database. Resign and undo works.
  • Chatting and announcing works in games. Chats are now logged to the database.
  • Can resume unfinished games.
  • Demo games work.
  • Review games (both started after a game and loaded from a game list) work.
  • Rengo is nearly done. Some dialogues still need to be rewritten (eg, "xxx has resigned, yyy has won" needs to be "xxx has resigned. yyy and zzz have won.").

Harleqin: Excuse me, shouldn't it be "www and xxx have resigned. yyy and zzz have won." ?

Mef: In a rengo if either one of the players on a team resigns the game is over.

Harleqin: Well, no. The players on a team agree on whether they want to resign, at least as I know it from real-life rengo. That is one case in which they are allowed to talk.

Mef: Well, yes you do typically want to discuss with your partner first, however there's not much point to continuing the game if one player on a team refuses to play.

DrStraw: The rules, as I understand them, state that a player may ask his partner "May I resign" and the partner can answer with either "yes" or "no" but may not discuss it. Thus the phrase as quoted by wms is appropriate.

  • More work on demo/review. Finished the logic for giving control working, and playing with two players of the teacher's choice.
  • Simuls work.
  • Server tracks subscriptions. Can track multiple subscription periods, so people who stop subscribing and then resubscribe later will have access to the games from their first subscription as well as their new subscription.

SirLyric: WMS, I know you keep this page pretty sparse so I'll keep it brief, but as someone who requested this feature and now seeing it in place, I'd like to say it feels really good to know we players are really listened to. We appreciate all your hard work. +

wms: Thanks SirLyric. To be honest, it should have been this way all along, it somehow just never occurred to me when I was programming...but, 3 months aftering writing the KGS Plus code, when the first person got bitten by this, I realized how stupid it was, and I felt really bad about the trouble it causes. The bad news is that by then the server, the client, and the database were all set up to handle only one subscription period. :-( Oh well, at least it will be fixed at last when 3.0 is out.

  • Audio works.
  • Recording lectures works.
  • Playback works.
  • Global games windows (three now: open games, active games, and fan games).
  • Avatar upload & accepting.
  • Lost password recovery code
  • JSP pages done:
    • Game archives web page
    • Game archive .tar/.zip servlet
    • Rank graph page
    • Top 100 page
    • Tournament web pages work
  • Tournament system done

OK, that's it. Time to do one last scan for obviously missing things. This may take a while.

Here's something interesting (well, interesting to me). My code base was originally split into go related code and KGS related code. In this latest release, I split the KGS code into code for a go server, and code that has nothing to do with go. Not counting the GUI, here's the line counts:

  • go library: 14541 lines (bigger than I expected! But then I've been writing code here for about 8 years now)
  • generic server+client: 58603 lines
  • go server+client (really connects the generic server+client to the go library): 7277 lines

So depending on how you look at it, the amount of code on KGS that is really related to go is either 11% of the code (if you consider the go library "not part of the server") or 27% (if you do count it as "part of the server").

I think that the go server parts could be shrunk a lot more if Java supported reified generics and inheritable constructors. I have a lot of classes that override current classes just so that they can construct objects of a type to match their generic parameters. Just reified generics would be nice, but adding the inheritable constructors would take out a lot of annoying code.

I left the GUI code out of this because I didn't put nearly as much effort into cleanly separating this code out - most of the time I just hauled it into the go-related part. If I ever need it elsewhere, I'll look into how to split it up then.


This is a copy of the living page "KGS Status" at Sensei's Library.
(OC) 2005 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About