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

[Carsten Wenderdel]

On 14. Nov 2023, at 19:42, Frank Berger wrote:
> 
>>> 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).

Hi Frank,

what do you mean with "you should do error handling for http“?

You only have to handle the errors the API specify. My API draft specifies 
exactly two error codes:
- 400 for client errors like „opponent has 16 checkers on the board“
- 500 for server errors like „could not find neural network files“

Every other error code returned by the server is then basically an 
implementation bug.

Those errors need to be handled anyway. I believe HTTP and it’s libraries make 
this super easy to implement, otherwise you had to reinvent it.

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

I also believe that there should be two mechanisms. The binary one could be 
simple C function calls, similar to what Øystein wrote in his email. Pure 
functions preferred.

Something in that direction exists in wildbg:
https://github.com/carsten-wenderdel/wildbg/blob/main/docs/user/wildbg-c.md
https://github.com/carsten-wenderdel/wildbg/blob/main/crates/wildbg-c/wildbg.h

This could also be the first step for GnuBG. The engine and the GUI could 
communicate via those C calls, no new library needed, everything compiled to 
one binary.
External developers could then be able to compile GnuBG without the GUI and its 
GTK dependencies and use it as a C library.

Around this C library we could then write a wrapper with a text based protocol. 
As so many languages support interfacing with C, we could even pick the 
language here.

I don’t believe in two text based protocols building on top of each other. If 
there is a telnet/string based one and a HTTP based one, they would be two 
different protocols.
If both had to be implemented, the implementations would be independent from 
each other.

There is a lot we seem to have in common with our ideas. Is this right?
- It’s a good idea to separate engine and GUI.
- It should be a server/client model, so the GUI asks, the engine answers.
- Stateless, no match information in the engine.

Best, Carsten