Are you not living in reality and only accepting clients for linux and not windows?
Yeah, I'm pretty sure I'm living in reality; the sky is blue, the sun is bright, my taxes are high, and the local gravitational acceleration is 9.80 m/s.
Where did I say that the server wouldn't accept Windows clients? The last time I checked, Windows applications can be written in C++ and can use TCP/IP. I've only implied that others will have to write Windows clients; I'll help as much as I reasonably can.
Maybe there is a misunderstanding in how we should interpret:
"2) The entire client side programming API and the supporting common client side source should be open as well in order to make third party client creation and maintenance as fast and easy as possible. "
I interpreted the above as that the programming API source code should be open, as well as the code of the client.
That second we call open source. That first means it's not windows as their API is not open source at all, but closed source and they also claim copyright at everything, especially at the device context.
diep wrote:Would you accept strategic concept changes proposed by others?
Everything useful would be considered, but not necessarily accepted.
Do you think you are the best person to take decisions regarding protocol for such server?
Gosh no, Vincent! Actually, I'm probably the WORST person on the planet to make these decisions! In fact, I'm so bad that you shouldn't pay any attention to me at all!
diep wrote:Maybe there is a misunderstanding in how we should interpret:
"2) The entire client side programming API and the supporting common client side source should be open as well in order to make third party client creation and maintenance as fast and easy as possible. "
I interpreted the above as that the programming API source code should be open, as well as the code of the client.
No, only the protocol API and the protocol supporting library routines in the client need to be open. The rest of the client can be closed. And by client, I mean a GUI or an engine or a combination of the two.
diep wrote:Maybe there is a misunderstanding in how we should interpret:
"2) The entire client side programming API and the supporting common client side source should be open as well in order to make third party client creation and maintenance as fast and easy as possible. "
I interpreted the above as that the programming API source code should be open, as well as the code of the client.
No, only the protocol API and the protocol supporting library routines in the client need to be open. The rest of the client can be closed. And by client, I mean a GUI or an engine or a combination of the two.
"protocol API", what's that for ballony?
You want to create yet another useless API, let me guess in a FUNCTIONAL language?
I am very enthusiastic about this project, and would be willing to help. I've actually been working on something similar, with the primary focus being robust, extensible support for chess variants.
Although you'll probably want to vomit when I suggest this, I'd recommend using .NET for the server. It's very robust, feature-rich, and cross-platform (thanks to the MONO project.) The Lidgren Network Library for .NET is excellent.
Because it basically all exists, except considering some irrelevant specs on its internnal workings that no user would ever notice, I think it would be a giant waste of time...
I think a great project is to continue HG's work on his FICS-compatible server, which already has many features and supports many variants.
A wish list:
- Make it cross platform, at least windows and linux, instead of linux only.
- Make it easier to set up and get running, for someone who wants to experiment with the server. (I think I remember hearing that the server is tricky to set up.)
Since the codebase is very old, maybe it would be a good idea to rework some of the code, piece by piece, if that makes the code easier to work with and maintain. That would make more sense to me that rewriting the whole thing.
It's clear that if chess variants are to be supported in a non-kludgy manner then provision must be made for support in the early design. I have no problem with this although I'm not a big fan of variants myself.
How important is variant support for chess program authors? Other than an occasional chess960 tournament, I can't think of any significant international events that have used chess variants. Remember that effort spent on variant implementation is effort taken away from working on other features.
Also, there are well known, efficient algorithms for game termination detection for orthodox chess. Can this be said for most or all variants? Since the server must be able to detect game termination, could some variant support impose a significant extra computational load?
