linux Go clients
kakung
http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/jago
slawek wrote:
> Any suggestions for a good client for linux?
> So far I have used WINIGC but I want you leave Windows...
>
> slawek
Scott Peace-Miller
http://kgs.kiseido.com/~wms/comp/cgoban/
/spm
In article <3A76E76C...@komes.com.pl>,
slawek <sla...@komes.com.pl> wrote:
> Any suggestions for a good client for linux?
> So far I have used WINIGC but I want you leave Windows...
>
> slawek
>
Sent via Deja.com
http://www.deja.com/
William M. Shubert
is talking about. It works fine as an IGS or NNGS client, but I am no
longer adding new features. When I get a bug fix from somebody else, I
add it to the code and do a new release, but all of my development time
is spent on CGoban 2, which has a KGS client instead of an IGS client.
--
Bill Shubert
http://www.igoweb.org/~wms/
The Nose Who Knows
> As the author of CGoban, I should say that this is CGoban 1 that Scott
> is talking about. It works fine as an IGS or NNGS client, but I am no
> longer adding new features. When I get a bug fix from somebody else, I
> add it to the code and do a new release, but all of my development
> time is spent on CGoban 2, which has a KGS client instead of an IGS
> client.
I'm led to believe that you're currently not interested in adding
features to CGoban 2.x that don't directly relate to the Kiseido Go
Server. (If that's not true in some way, please let us know.)
If so, would you be interested in one of the following:
- An independent Java port of the CGoban 1 client code, so that you
can add it to CGoban 2 and we can use that for all major servers;
- Releasing the specs (not source) of the KGS client protocol so that
a Free Software client (such as Jago) can be written/modified to
connect to KGS;
- Having someone reverse-engineer the KGS client protocol, clean-room
style, to allow such software to be written?
I'm really interested in your views on this, Bill (and others who have
something to say). KGS is a great resource, but it is irksome to be
forced to use non-free software to make use of it.
(For those unfamiliar with software licensing issues, Free in this sense
has to do with freedom, not price.)
Free Software explanation:
<http://www.gnu.org/philosophy/free-sw.html>
Jago (released under the GNU General Public License):
<http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/jago/>
CGoban 2.x (KGS client):
<http://kgs.kiseido.com/en_US/download.html>
CGoban 1.x (IGS, NNGS client):
<http://kgs.kiseido.com/~wms/comp/cgoban/>
--
\
`\
_o__) BIGNOSE
Nick Wedd
Nose Who Knows <bignose-h...@and-zip-does-too.com.au> writes
>I'm led to believe that you're currently not interested in adding
>features to CGoban 2.x that don't directly relate to the Kiseido Go
>Server. (If that's not true in some way, please let us know.)
I believe/hope that work is being done on the "Score Estimator" of
CGoban2. This is not directly relevant to its use with KGS.
>If so, would you be interested in one of the following:
>
> - An independent Java port of the CGoban 1 client code, so that you
> can add it to CGoban 2 and we can use that for all major servers;
CGoban1 and CGoban2 are different and unrelated programs. The choice of
names is unfortunate. CGoban1 runs under Unix, and is used as a client
for IGS, NNGS, WING etc. CGoban2 runs on any system that supports Java,
and is an SGF viewer and editor, and a client for KGS. They are written
in different languages. Trying to bundle the two together would be
difficult, and achieve nothing useful.
You refer to "all major servers". I know of seven servers which might
qualify for this description, regularly having over 100 users. They use
seven different protocols. I very much doubt that the author of the
CGoban programs is willing or able to support all these protocols.
> - Releasing the specs (not source) of the KGS client protocol so that
> a Free Software client (such as Jago) can be written/modified to
> connect to KGS;
>
> - Having someone reverse-engineer the KGS client protocol, clean-room
> style, to allow such software to be written?
>
>I'm really interested in your views on this, Bill (and others who have
>something to say). KGS is a great resource, but it is irksome to be
>forced to use non-free software to make use of it.
CGoban2 is free in the monetary sense. You can download it from the KGS
web site at http://kgs.kiseido.com/en_US/download.html
IGS clients are not free, in the sense which you indicate below. IGS
claims proprietary rights over the protocol which it uses.
>(For those unfamiliar with software licensing issues, Free in this sense
>has to do with freedom, not price.)
>
>Free Software explanation:
> <http://www.gnu.org/philosophy/free-sw.html>
>
>Jago (released under the GNU General Public License):
> <http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/jago/>
>
>CGoban 2.x (KGS client):
> <http://kgs.kiseido.com/en_US/download.html>
>
>CGoban 1.x (IGS, NNGS client):
> <http://kgs.kiseido.com/~wms/comp/cgoban/>
Nick
--
Nick Wedd ni...@maproom.co.uk
The Nose Who Knows
> In article <slrn97uc8c.hbo.b...@zipperii.zip.com.au>, The
> Nose Who Knows <bignose-h...@and-zip-does-too.com.au> writes
> >I'm led to believe that you're currently not interested in adding
> >features to CGoban 2.x that don't directly relate to the Kiseido Go
> >Server. (If that's not true in some way, please let us know.)
>
> I believe/hope that work is being done on the "Score Estimator" of
> CGoban2. This is not directly relevant to its use with KGS.
Let me rephrase then; "features ... that would not directly benefit the
use of KGS". I.e., getting it to work with things other than KGS.
> > - An independent Java port of the CGoban 1 client code, so that you
> > can add it to CGoban 2 and we can use that for all major servers;
>
> CGoban1 and CGoban2 are different and unrelated programs.
> [...]
> They are written in different languages.
Yes; that's why I refer to "a Java port" of the CGoban 1.x client code.
> You refer to "all major servers". I know of seven servers which
> might qualify for this description, regularly having over 100 users.
> They use seven different protocols.
Really? I'm curious to know which of them use protocols other than the
KGS, NNGS and IGS protocols; because I don't know of any other protocols
supported by the "major Go clients".
> I very much doubt that the author of the CGoban programs is willing or
> able to support all these protocols.
I was mistaken in this, anyway; the CGoban 1.x source is released as
GNU GPL, which means that its freedom cannot be restricted by including
it under a different license. The only person who has the right to
release it under a different license is Bill himself -- but this would
involve exactly the work that (I assume) he's not doing right now on
CGoban 2.x.
So I guess our only hope at the moment is a release, or reverse
engineering, of the KGS protocol so the client end can be reimplemented
without proprietary code.
> IGS clients are not free, in the sense which you indicate below. IGS
> claims proprietary rights over the protocol which it uses.
I wasn't aware of that. Protocols, though, are not an copyrightable
expression, last I heard. IGS can claim copyright on their own code,
but not on the data generated during my IGS session.
Sadly, there are currently forces at work (UCITA and the DMCA in the
USA, for example) that would render it impossible for someone to
generate an independent KGS or IGS client. Freedom of software becomes
even more important.
<http://www.public.asu.edu/~kbrown3/cse200/reveng_dmca.html>
--
\
`\
_o__) BIGNOSE
William M. Shubert
...
> I'm led to believe that you're currently not interested in adding
> features to CGoban 2.x that don't directly relate to the Kiseido Go
> Server. (If that's not true in some way, please let us know.)
At the moment I am only interested in adding KGS features and SGF
editing features to CGoban 2. This is all that I have time for at the
moment.
> If so, would you be interested in one of the following:
>
> - An independent Java port of the CGoban 1 client code, so that you
> can add it to CGoban 2 and we can use that for all major servers;
If you want to port CGoban 1 to Java, great! My source code for CGoban 1
is freely available so you can do this. But it seems the benefit of
merging CGoban 1's IGS client with CGoban 2's KGS client is rather small
- the two servers have very different systems, not just in the protocol
but also in the way users interact with them, so the only shared code
would be the graphics for the board. It seems that keeping the two
clients in separate programs would be best.
> - Releasing the specs (not source) of the KGS client protocol so that
> a Free Software client (such as Jago) can be written/modified to
> connect to KGS;
I change the KGS protocol fairly often, so any protocol document that I
release would be out of date before a client could be written. I've had
jobs where I was implementing a spec that was constantly changing, and
do not want to lead other people into that misery! And further I just
don't have time to support the client writers and the users of these
other clients.
> - Having someone reverse-engineer the KGS client protocol, clean-room
> style, to allow such software to be written?
There's nothing I can really do to stop you from doing this, but again,
if other KGS clients are written I will have to support them and I just
don't have the time to do that, so I will not help you if you try to do
this.
> I'm really interested in your views on this, Bill (and others who have
> something to say). KGS is a great resource, but it is irksome to be
> forced to use non-free software to make use of it.
I also prefer open source programs. As anybody who has looked at my web
pages knows, I often release source code to programs I write. In this
case I won't.
Earlier, I twice said that "I will have to support other clients and
their users". One of my fears in KGS is putting myself in a position
where all of my time is consumed doing support and I have no time to do
the "fun work" of enhancing it. I know that if I give away the protocol
or source code, I *will* get questions from programmers. And if other
clients are written, they'll break when I change the protocol to add a
feature, and then I *will* get questions/complaints from their users. In
my work on another server (NNGS), there were often help requests when
the problem was with a client, not with the server. On KGS this problem
would be much larger because new features are constantly being added and
improvements that change the protocol are constantly being made. I can't
ignore these questions saying "independant clients are none of my
business"; once I open the door to these clients, then the questions
*are* my business, and until I'm willing to deal with them I will not
release the source code or protocol.
> (For those unfamiliar with software licensing issues, Free in this sense
> has to do with freedom, not price.)
>
... list of open source links omitted ...
--
Bill Shubert
KGS Admin and author
Bantari
sp...@and-zip-does-too.com.au) said...
> Really? I'm curious to know which of them use protocols other than the
> KGS, NNGS and IGS protocols; because I don't know of any other protocols
> supported by the "major Go clients".
Depends on the definition of "major". If you go by the number of
users regularily exceeds 100 then at least both Yahoo and MGZ use
distinct protocols that are differnt from IGS/NNGS/WING/etc and from KGS.
There are some other non-telnet servers too, but I am not sure about
attendance.
If by "major" you define IGS/NNGS/WING and close relatives, then
you are right. :-)
--
________________________________________
-Bantari
e-mail: kapr...@yahoo666.com (remove the 666)
homepage: http://home.san.rr.com/rafgo
Nick Wedd
Nose Who Knows <bignose-h...@and-zip-does-too.com.au> writes
>> You refer to "all major servers". I know of seven servers which
>> might qualify for this description, regularly having over 100 users.
>> They use seven different protocols.
>
>Really? I'm curious to know which of them use protocols other than the
>KGS, NNGS and IGS protocols; because I don't know of any other protocols
>supported by the "major Go clients".
Here are the figures for the numbers of users I typically find, at the
busiest servers:
ItsYourTurn 700
IGS 350
CyberKiwon 340
NeoStone 330
Yahoo 200
BadukWorld 140
MS Zone 100
These figures are biassed by the fact that I connect in the European
evening, when most East Asians are asleep. CyberKiwon often has over
1000 users earlier in the day.
ItsYourTurn is not a realtime server. You visit it with a browser, and
click on the board to make your move, which I suppose is sent to it by
http. It sends you an email when your opponent has moved. The figure
of 700 is for the number of people involved in on-going Go games - few
of them will actually be connected ay any one time.
CyberKiwon requires the use of a custom client, for Windows, which you
download from its site.
NeoStone requires the use of another custom client, for Windows, which
you download from its site. However, this gives access to four
different servers, which support different languages and may be in
different countries. The figure of 330 is for the Chinese one.
Yahoo and BadukWorld both use java, which downloads automatically when
you connect to its web site with a browser. The java applets they use
are different.
MS Zone downloads its own client onto your Windows system, using non-
standard Microsoft-specific tricks.
The Nose Who Knows
> In article <slrn97uibo.hbo.b...@zipperii.zip.com.au>, The
> Nose Who Knows <bignose-h...@and-zip-does-too.com.au> writes
> >KGS, NNGS and IGS protocols; because I don't know of any other protocols
> >supported by the "major Go clients".
>
> Here are the figures for the numbers of users I typically find, at the
> busiest servers:
>
> ItsYourTurn 700
> IGS 350
> CyberKiwon 340
> NeoStone 330
> Yahoo 200
> BadukWorld 140
> MS Zone 100
>
> These figures are biassed by the fact that I connect in the European
> evening, when most East Asians are asleep. CyberKiwon often has over
> 1000 users earlier in the day.
My definition of "major Go server" is biased by feature set; I suppose
what I mean is better expressed by "real Go server" or "serious Go
server", which makes my snobbishness in this regard more apparent. I
exclude those that don't provide interactive game review, ability to
handicap games, and automatic player ranking. This rules out (I
believe) Yahoo, MS Zone, ItsYourTurn -- any others?
This is rather biased, I realise that now. I still feel it is a valid
distinction in the context of a "major Go client/server protocol". I
don't see that supporting a proprietary protocol that doesn't provide
the features described above should be a priority, since "better"
alternatives already exist.
That was my rationale; you've shown that it is definitely arrogant, and
possibly flawed. I guess what I'd like to see is an ueber-client that
is Free Software and can talk to any of the, shall we say, "advanced" Go
servers available today, and potentially in the future. This would, I
feel, go a long way toward exerting pressure for a common, open protocol
(or set of protocols) for all Go servers, which would in turn lower the
barrier to entry for the advanced servers.
Any comments in this light?
--
\
`\
_o__) BIGNOSE
Bantari
sp...@and-zip-does-too.com.au) said...
Hmm... I would also love to see such an "uber-client".
Preferably, as a part of some kind of "Go Office" which would be a
package of software to edit games, store them, database them, print out
Go documents, and so on... preferably a free and open-source. :-)
But, realistically, I do not see it happening in near future.
IGS/NNGS protocols are available, I have a friend who cracked the Yahoo
protocol, but other than this, it will probably not be easy to get hold
of the others. Plus - some protocols, like the KGS one, are too fluid to
base a major software on it. For now...
But, all in all, its a nice thought. :-)
Some time ago I remember somebody suggesting writing a client for
the telnet servers which would combine all the servers into one platform
- at least from the user's perspective. You would be able to log on to
all the servers simultaneously and, for example, when you do a "who" you
would see the list of all the people connected to each of the servers,
and so on. This, I think, is much more realistic goal, although there
are still some problems - for example different ranking systems on
different servers...
Barry Phease
wrote:
>Here are the figures for the numbers of users I typically find, at the
>busiest servers:
>
> ItsYourTurn 700
> IGS 350
> CyberKiwon 340
> NeoStone 330
> Yahoo 200
> BadukWorld 140
> MS Zone 100
>
>These figures are biassed by the fact that I connect in the European
>evening, when most East Asians are asleep. CyberKiwon often has over
>1000 users earlier in the day.
You miss out Lianzhong (www.ourgame.com) which claims to have an
average of 20 million connections each day and a maximum of 70 000
simultaneous connections. Of course this has other games besides go,
but still the numbers connected and playing/watching go are much
higher than any of the above.
Lord Tim Brent
do it before opponent is known on Yahoo.
Tim
--------------------
Duchy Of Grand Fenwick
The Church Beatle will now pass amongst you
No foreign coins please.
Bantari
said...
> Both itsyour turn and Yahoo let you handicap games,however you have to
> do it before opponent is known on Yahoo.
This is not true. On Yahoo, you sit on a table, wait for
opponent. When he comes, you talk, set handicap, and start game.
Of course, without a rating system, you have to either trust the
opponent or know him to set proper handicap.