bug-gnubg
[Top][All Lists]
Advanced

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

Re: Bug-gnubg Digest, Vol 237, Issue 2


From: Joseph Heled
Subject: Re: Bug-gnubg Digest, Vol 237, Issue 2
Date: Wed, 15 Nov 2023 07:53:40 +1300


I am firmly in the text-based camp. You ask/set the "engine" in text and get answers back in text. 
The transport layer can be anything, and you can have any number of them, depending on system and needs.
But I would try to leave the absolute minimum "BG" handling outside the "engine". The engine should be as comprehensive as possible. 

If there is interest, I can try and give more details later.


On Wed, 15 Nov 2023 at 07:43, Frank Berger <frank@bgblitz.com> wrote:
>
> From: Guido Flohr <guido.flohr@cantanea.com>
>> On 13 Nov 2023, at 21:22, Carsten Wenderdel <chrisforen@outlook.de> 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.



>
>> 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).

Additionally I believe we need two mechanisms. One simple easy to implement one, mainly addressing play against the machine as described by Carsten and a fast one that might be needed for analysis, rollouts etc.
based on binary stuff, shared memory etc.  But it is sufficient to have the simply one first and have a place holder for the latter to be done if it is really needed.

ciao
Frank






reply via email to

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