I agree - use stdin/stdout for the interface. A web based app can be
built on top of such a source, a non-gui app suitable for batch
procesing for example would be a nightmare to scrape from a web
interface. U hesitate to even estimate how difficult a portable web
interfcase would be to construct, the gtk interface is already a mess of
special case support.
On 11/17/23 12:05, Guido Flohr wrote:
Him
On 14 Nov 2023, at 20:42, Frank Berger <[email protected]> wrote:
From: Guido Flohr <[email protected]>
On 13 Nov 2023, at 21:22, Carsten Wenderdel <[email protected]> wrote:
In chess there is UCI, an interface understood by virtually all engines, bots
and GUIs. Wouldn’t it be great if we had something similar for backgammon?
Someone could write a new engine or GUI without worrying too much about the
other. If someone wanted to create a JavaScript or Flutter GUI on top of GnuBG,
it would be possible.
I have both implemented UCI and xboard and imho both ”protocols” are terrible.
We should learn from their mistakes.
What suggestions do you have? I don’t know much about UCI other than it is
based on std input/output and text based.
The problem is that the specification is hard to understand and sometimes
ambiguous.
In chess UCI uses standard input and output. I believe a modern interpretation
should be based on web technologies.
Absolutely.
I personally like input/output because it is dead simple and elegantly
addresses some issues with the probably most common scenario client and
AI-server on the same computer (several instances, no need to
communicate/negotiate ports) and avoids unnecessary complexity (if you have
http you should do error handling for http).
Obviously you’re not the only fan of raw I/O. Therefore, it’s probably a good
idea to just stick to it, and rather offer a connector that translates the
protocol to a web api for those that prefer it. That should make everybody
happy and not very hard.
Cheers,
Guido
