Life In 19x19
http://www.lifein19x19.com/

The future of KGS
http://www.lifein19x19.com/viewtopic.php?f=24&t=8003
Page 1 of 12

Author:  Pippen [ Sat Mar 02, 2013 7:32 am ]
Post subject:  The future of KGS

Where does WMS see KGS in 5 years? Is it set or will there be major developments & changes coming up? What would u like? I definitely would love to see KGS continue for a looong time since IMHO it's the best Go-Server, a Server where I found many nice people and conversations whereas on other server you can "just" play....

Author:  Uberdude [ Sat Mar 02, 2013 7:33 am ]
Post subject:  Re: The future of KGS

Are you aware he is working on an html client?

Author:  Pippen [ Sat Mar 02, 2013 12:47 pm ]
Post subject:  Re: The future of KGS

Uberdude wrote:
Are you aware he is working on an html client?


Nope. Does this change anything more than that the client will be able to run through a webbrowser? Like ranking, graphics and so on?

Author:  Javaness2 [ Sat Mar 02, 2013 12:54 pm ]
Post subject:  Re: The future of KGS

The HTML 5 client might let us have some cool new stuff, if it's robust enough.

Author:  Pippen [ Sat Mar 02, 2013 1:49 pm ]
Post subject:  Re: The future of KGS

Ah..ok. I thought if you program in HTML you basically wanna create a server that is reachable through a webrowser.

Author:  wineandgolover [ Sun Mar 03, 2013 4:03 am ]
Post subject:  Re: The future of KGS

Hmmm, I love KGS. I play 99% of my online games there.

But, "is working on an HTML client" and "might let us have cool new stuff" are a step or two below vaporware on the software readiness list.

If WMS is still full-time employed, and not accepting coding assistance, then I'd moderate expectations for timing and features. I would very much love to be proven wrong and I hope that WMS is practicing the mantra, "under-promise and over-deliver."

Author:  quantumf [ Sun Mar 03, 2013 10:11 am ]
Post subject:  Re: The future of KGS

The cost benefit analysis eludes me. To make a client as functionally capable and as stable and bug-free as the existing cgoban client will be a pretty epic task. And for what, exactly? It might silence the vocal anti-java minority, but I can't think of a legitimate reason, except perhaps to fight off the challenge of Kaya and others. Kaya and others are not mounting any immediate challenge, but I suppose there's always the risk that when they eventually get a compelling alternative, it will be too late to do anything about it. But then I wonder if wms even cares that much. Since it's not his primary source of income, perhaps he will even welcome a credible english language alternative and can retire from the stress of running kgs.

Author:  Phelan [ Sun Mar 03, 2013 11:08 am ]
Post subject:  Re: The future of KGS

quantumf wrote:
The cost benefit analysis eludes me. To make a client as functionally capable and as stable and bug-free as the existing cgoban client will be a pretty epic task. And for what, exactly? It might silence the vocal anti-java minority, but I can't think of a legitimate reason, except perhaps to fight off the challenge of Kaya and others. Kaya and others are not mounting any immediate challenge, but I suppose there's always the risk that when they eventually get a compelling alternative, it will be too late to do anything about it. But then I wonder if wms even cares that much. Since it's not his primary source of income, perhaps he will even welcome a credible english language alternative and can retire from the stress of running kgs.

I think the idea is that people have always wanted to play on KGS through college/corporate firewalls, or systems that can't use java. An HTML client would work for that. I don't know if he ever gave reasons.
By the way, I think he had a page on google plus detailing the progress on that, but don't remember the link.

Author:  Samura [ Sun Mar 03, 2013 12:26 pm ]
Post subject:  Re: The future of KGS

Phelan wrote:
I think the idea is that people have always wanted to play on KGS through college/corporate firewalls, or systems that can't use java. An HTML client would work for that. I don't know if he ever gave reasons.
By the way, I think he had a page on google plus detailing the progress on that, but don't remember the link.


Yes! The day I can play between my classes at college on my iPad will be a happy day!

Author:  Uberdude [ Sun Mar 03, 2013 1:26 pm ]
Post subject:  Re: The future of KGS

quantumf wrote:
The cost benefit analysis eludes me. To make a client as functionally capable and as stable and bug-free as the existing cgoban client will be a pretty epic task. And for what, exactly?


I imagine part of wms's reasons for doing it could be for his personal enjoyment and benefit: having fun programming, learning new technologies and skills (good CV fodder).

Author:  Marathon [ Sun Mar 03, 2013 1:42 pm ]
Post subject:  Re: The future of KGS

I think another motivation is to reduce the number of clients, and therefore, the future work needed in making changes.

The current system's main client is the web-start client, with two versions (with or without file associations). Then, there is the applet (Java plugin) client. I imagine the applet client is substantially the same as the web-start, but with some features disabled (because browser/applet security prevents their use) and "life cycle management" methods. But then there is the Android client, which I imagine is completely different than the others. So, this project will essentially reduce the number of clients from two to one.

In addition, there is the GTP client for bots. I've no idea how that fits into the picture.

Also, it looks like the current server will remain, as he has said he is converting the existing client to act as an intermediate server. So, the HTML 5 client will communicate with the new server, and the new server will communicate with the current server.

Author:  PaperTiger [ Sun Mar 03, 2013 2:45 pm ]
Post subject:  Re: The future of KGS

quantumf wrote:
But then I wonder if wms even cares that much. Since it's not his primary source of income, perhaps he will even welcome a credible english language alternative and can retire from the stress of running kgs.


Considering that he hasn't gotten around to make a one line change to fix the stone clicking sounds in over a year, it is evident he really doesn't care.

Author:  speedchase [ Sun Mar 03, 2013 3:32 pm ]
Post subject:  Re: The future of KGS

Marathon wrote:
I think another motivation is to reduce the number of clients, and therefore, the future work needed in making changes.

The current system's main client is the web-start client, with two versions (with or without file associations). Then, there is the applet (Java plugin) client. I imagine the applet client is substantially the same as the web-start, but with some features disabled (because browser/applet security prevents their use) and "life cycle management" methods. But then there is the Android client, which I imagine is completely different than the others. So, this project will essentially reduce the number of clients from two to one.

I really don't think that is it. Java is generally considered much easier to maintain than HTML because there is only one JRE (well here are more but no one really cares if you support the others or not) while there are tons of browsers, and way more comparability issues.

Author:  Kirby [ Sun Mar 03, 2013 4:07 pm ]
Post subject:  Re: The future of KGS

quantumf wrote:
The cost benefit analysis eludes me. To make a client as functionally capable and as stable and bug-free as the existing cgoban client will be a pretty epic task. And for what, exactly?...


Say it's the 90s, oh about the time that KGS was initially being developed. Making a go server and client functionally capable and stable would have been a pretty epic task. And for what, exactly?

Anyway, the most pressing reason to have a browser client is to stay modern, in my opinion. KGS is cool, and was pretty well designed, but it does have an old feel to it.

Author:  deja [ Sun Mar 03, 2013 4:47 pm ]
Post subject:  Re: The future of KGS

I've been away from Go (and L19) for some time, so this may be a dumb question, but is there a better or even equivalent client for teaching? For all its warts, it still seems to be the most versatile compared to the others.

Author:  LocoRon [ Sun Mar 03, 2013 6:20 pm ]
Post subject:  Re: The future of KGS

Phelan wrote:
I think he had a page on google plus detailing the progress on that, but don't remember the link.


https://plus.google.com/108736506961432085848/posts

The last post is from September... and the last post about the web client (from a quick perusal) is last March. Not that I really care. I hate browser-based apps. Although, it would be nice to refer people to KGS without having to worry about whether or not they have java installed and functional.

Marathon wrote:
I think another motivation is to reduce the number of clients, and therefore, the future work needed in making changes.


Part of the (stated) reason he has developed an Android client but not an iOS client is because Android apps are developed in Java. This means a large portion of the codebase between Android app and desktop app is the same. All that needs to be handled separately is the UI code.

speedchase wrote:
Java is generally considered much easier to maintain than HTML because there is only one JRE (well here are more but no one really cares if you support the others or not) while there are tons of browsers, and way more comparability issues.


This. So much this.

Author:  jts [ Sun Mar 03, 2013 6:39 pm ]
Post subject:  Re: The future of KGS

I don't really think KGS needs more of this or that feature for its own sake, but different people are irked by different aspects of KGS, and I worry that someday soon there will no longer be a central gathering-point for Western Go players. I guess we can still all play on Tygem, so it's not the end of the world, but it would still be sad.

Author:  Kirby [ Sun Mar 03, 2013 8:52 pm ]
Post subject:  Re: The future of KGS

LocoRon wrote:
...

speedchase wrote:
Java is generally considered much easier to maintain than HTML because there is only one JRE (well here are more but no one really cares if you support the others or not) while there are tons of browsers, and way more comparability issues.


This. So much this.


The sentiment is probably true, but I don't think the statement, in itself, is completely true. For one, there are multiple versions of the JRE. It's not too infrequent that you have methods that become deprecated. So if you're using newer methods for stuff, you either have to force people to install yet another version of java on their machine, perform different behavior at runtime depending on java version, or run the risk of a runtime exception if you just don't care.

Secondly, if you follow the W3 html standards, you are less likely to run into compatibility issues than if you just write ad-hoc html.

To be honest, I like java. It's probably my second favorite programming language. But looking at the trends of the Internet, it's not the way of the future. You might have backend code on the server that content creators maintain because the language is easy and portable, but it's too much of a pain for everyday users to deal with.

People don't want to install 4 different versions of java on their computer. People don't want to keep updating flash software for their browser (which is not about java, but just something annoying). People like being able to go to a website that just works - you don't have to install any features, you just type in the url, and it's there.

This is my interpretation, anyway. There may be efforts that developers make to allow for people to have this convenience, but making things as easy as possible for the end-user (who may not be a technical person) is the way of the future (as usual, in my opinion).

And if Java is going to be a part of this future (for the presentation layer for end users), it needs to have some redesign.

Author:  quantumf [ Sun Mar 03, 2013 10:49 pm ]
Post subject:  Re: The future of KGS

Marathon wrote:
I think another motivation is to reduce the number of clients, and therefore, the future work needed in making changes.


As stated elsewhere, porting between different java environments (Android is java) is relatively trivial compared to porting to a Javascript environment.

Furthermore, adding a new HTML5/JS client doesn't equal abandoning the existing clients. Since reaching the existing functionality will take ages, most likely a limited capability initial version would first appear, and then go through a couple of years of iterating to reach or exceed the existing java client(s). So it's really just adding a new client, I don't see the existing clients going anywhere for at least a few years.

Author:  quantumf [ Sun Mar 03, 2013 10:52 pm ]
Post subject:  Re: The future of KGS

PaperTiger wrote:
quantumf wrote:
But then I wonder if wms even cares that much. Since it's not his primary source of income, perhaps he will even welcome a credible english language alternative and can retire from the stress of running kgs.


Considering that he hasn't gotten around to make a one line change to fix the stone clicking sounds in over a year, it is evident he really doesn't care.


I'm pretty certain genuine bugs or performance problems would be addressed swiftly.

Page 1 of 12 All times are UTC - 8 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/