Malweth’s Metablog

Here’s a refinement of my idea shown below…

Firstly, there are a number of programs that do this, but the most notable is BIgo. This program contains Joseki/Fuseki information in a local database and provides this information when you play through the variations… Kogo’s Joseki Dictionary is similar, though in SGF format — you click on a letter to go to that variation.

My idea is…

1) Have an XML-RPC server on my web server that can take a point query and output the data (comments) for that point as well as all points linked to it (e.g. the “hard part”) the XML-RPC server should accept a login and password (or login and session ID) for any given query. With the appropriate authorization, comments and variations can be added.

2) Create a Visual Basic or Java based client to act as the “other end” of #1… this client should have a board display (user configurability can be added later) and a past-comment area. Someone with Admin access should be able to delete comments and variations. This client should be able to “home in” on a single game by choosing it from a list (perhaps a “premium” feature would be the ability to add your game to a list, otherwise you can only add variations).

If this is to work, more planning is probably required, but it seems like a decent idea…

Things to think about include:

• Learning VB (I only know the basics and VBA)


• Learning XML-RPC


• Stress problems (if 100 people are all using the system at one time, what type of load does my server incur)?


• Cost (based on Stress).


• Effort required


• Potential Licensing (Cost related)

I don’t really want to design something that’s going to be a premium service — this typically means usage is lessened. I do, however, want to create a system for collaborating on Go diagrams (not in real time) without having to resort to a web interface. Essentially, I want something that can do what CGoban can do without having users on at the same time…

One potential problem with this system is also overuse (if I’m REALLY lucky).

Another potential problem is that, if all of these games are kept in memory (database), size problems will appear very quickly.

Solutions for both might include:
One game per rank level per day/week…
In other words, the database is cleared (after a backup / sgf is created) daily or weekly and a new game is chosen for each rank - so there might, at any given time, be one 30-25k game, one 25-20k game, one 20-15k game, one 15-12k game, one 12-10k game, one 10-7k game, one 7-5k game, and one game per rank from 5k to 9d (and 1+ pro games). This would not only allow people to review games without having a burden on the system but would also help with problems of game “overload” (too many games to promote good collaboration).

Thanks to “sonicdesign” at fuitadnet for the XML-RPC info…! I’ll have to look at many possibilities for the client side…