gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] Fwd: [gnugo-devel] (GNU) Open source real time Go serv


From: Petr Baudis
Subject: Re: [computer-go] Fwd: [gnugo-devel] (GNU) Open source real time Go server
Date: Mon, 18 Jan 2010 11:14:33 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Jan 18, 2010 at 09:00:44AM +0100, Ben Lambrechts wrote:
> At first I tried to get in touch with the dev person behind KGS to
> discuss possible modifications to make kgs usable by near blind
> people, but he refuses to talk about opening the client, the protocol
> or the server. I wanted to avoid starting a new server from scratch (
> with the huge chances to not get anywhere ), but it looks like there
> is no way to discuss with him.

  I have been in touch with wms as well and I understand his reasons to
keep KGS in particular closed-source. At the same time I would certainly
prefer to use an open-source server and over time, I think most KGS users
would do the same for all the benefits (even if they have no idea what
"open-source" is).

> I am not a coding person myself, I do work in IT, but know nothing
> about code and my hobby is drawing ... Though, I would obviously help
> at all the other levels, get in touch with people, test, write
> documentation, translate, host and manage ... and so on.

  I think it is very difficult to just attract people to an abstract
idea or project and in my open-source history, I have pretty bad experience
with these - they aren't very likely to produce anything tangible. It is
a lot easier to just hack together a simple barely working prototype in
few days/weeks, then start rallying people around _that_. Most
community-driven OSS projects are a lot more evolution than intelligent
design and this corresponds to that fact. Bored developers like
something they can evolve and play with rather than just design and
dream up specs, and when it comes to the implementation, their attention
span is already over.

> I guess some members of your team are regular on those online Go
> servers. And maybe already though about such project. I do believe
> there is room for improvement and an open source alternative : A
> documented, open protocol and a server project.

  While working on it is probably pretty out of question for me due to
already being horribly overloaded, I have given this some thought and
researched a bit:

  (i) IGS is derivation of NNGS, which is free software (GPLv2)! It has
even seen some slight development in past few years.

  (ii) NNGS might be used as possible base of a modern go server. The
obvious advantage is that _right now_ you have something that you can
(in theory) compile, start, connect to and chat and play go on (!) and
you can evolve things from here.

  (iii) NNGS talks using same protocol as IGS. IGS' protocol being open,
there is huge host of Go software already supporting IGS, including
open-source software like qgo and many mobile applications. This is
huge advantage (though none of the open-source clients probably come
anywhere close to cgoban3 quality right now).

  (iv) NNGS code base is not pretty. I have seen much worse, but it's
not too nice to work with, over time many things would have to be
refactored. Two nice examples are hardcoded chatroom numbers and ugly
macro-based localization system (inst. of gettext). It's written in C.

  (v) IGS protocol does not support two key KGS features per se:
"open games" and presence in multiple chat rooms. It could be extended
to support these features and others in mostly-backwards-compatible
fashion, but only with some pain. (I'm also not sure about review
capabilities of the IGS protocol, but I have not investigated.)

  (vi) Using custom protocol makes sense if you are developing both
server and client hard-tied together by some underlying library,
akin to how KGS is built. However, I believe abstracting the protocol
is more work during the development, but much more viable solution
long-term, enabling free competition both on the server and the client
side, and allowing clients on a wide variety of platforms.

  If you are really interested, I think using NNGS as a code base merits
consideration, and I think using and extending already existing,
well-documented and already widely supported IGS protocol makes huge
amount of sense.

-- 
                                Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]