Hi all,
Note that I'm not actually answering anyone in particular. Last time I just wanted to add a post here and instead a new thread was created; sorry about that.
Warning, long and technical discussion of protocols ahead. People who are not interested can safely skip the whole post!
First I would like to summarise some past events. In 2015 I introduced a protocol that I call Hub in both Scan and the Hub GUI I use in tournaments. I recently described this protocol as Hub-1. Meanwhile, Bert used a slightly modified one that he called UDI. I got confused by the name and thought that he meant UCI with a few draughts-specific changes. I just want to say here that all is fine, including the UDI name; we can now move forward.
I look at Hub-1 and I think that it's not so bad, and therefore a good basis for something more solid. That is of course subjective. A very superficial overview is that there is an engine-initialisation phase at the beginning, and the rest is only a sequence of searches. To try to explain this philosophy (which originates from UCI) in terms of programming, I would say that the engine is seen as a module, and the protocol is its interface. The term GUI is used loosely and actually means any tool that can connect to an engine. It is often a user-facing GUI, but can also be a tournament manager, an adapter that translates to a different protocol or adds some functionality, a testing tool for programmers, etc ...
The main problem of Hub-1 is that it is not extensible. What I mean is: if we add features, we also have to change all the software that uses it. Ideally what we want instead is: if we add features, old software just ignores them and hopefully keeps working. I have a proposal that goes in that direction. I'm not claiming 100% magic here, as I'm not sure it is possible to be fully extensible, but something much better than the current state.
But a change is a change and will require updating existing code. So in this post I want to describe the main idea, and wait for feedback regarding potential interest. If for instance Bert gives me a green light (since he has written code that uses Hub), we are in business.
There are two aspects in Hub-1 that require changes before it's too late:
- important features like more detailed engine parameters and search information
- extensibility
It just so happens that one, but admittedly big, change in syntax allows both. In programming languages (PLs) it is called "named parameters" (as opposed to the more common positional parameters). Staying with the PL metaphor, you write f(x=2, y=3) instead of f(2, 3). This allows a lot of goodies like default values, flexible ordering, and extending the parameter list later. It is also arguably more readable, especially for long lists.
Back to protocols; UCI already has named parameters, like in this example:
Code: Select all
info score cp 20 depth 3 nodes 423 time 15 pv f1c4 g8f6 b1c3
I claim that this is not enough, however. It's difficult to parse (at least for the GUI) and, maybe surprisingly, not extensible. The reason is that UCI syntax is based on keywords. To separate the keywords (names) from the values, you have to know all the keywords in advance. Anything that is between two keywords is a value. But recall that a value can be empty (for flags) or contain spaces (like the PV). If later you try adding a keyword, existing software can break down.
There is an obvious solution: quoting, and that's what I'm proposing here. In the example above, "cp 20" and the PV would be quoted. Atomic values can be quoted too, it's just not required. With quoting, all the values become self-contained and there is a strict alternation between keywords and values (at least if we replace all the positional parameters). For machines this will work, but it's still somewhat unclear for humans without knowing the keywords. So I recommend something extra like "name=value" pairs, and just "name" for flags. A literal conversion of the UCI example would be:
Code: Select all
info score="cp 20" depth=3 nodes=423 time=15 pv="f1c4 g8f6 b1c3"
I don't have any strong preference between "=" and ":", whether to add spaces, or whether to add commas. We could even take insiration from command-line arguments, which originally had the same problem to solve.
So here is my plan:
- start from Hub-1
- redefine the syntax using quoting and name/value pairs (probably everywhere)
- add more detailed engine parameters and search information
There are a lot of other details that need thinking about, and I welcome such discussion. But what I've described here is the essence.
Now, let's not forget the drawbacks. Additionally to having to update existing code, it would be more difficult to parse than what we've got. Still only "INI file" level though; I'm not talking about parsing C++ here!
So, what do you think?
Last-minute paragraph. I'm just realising that maybe some programmers don't want to be involved in protocol details and see such discussion as too low level; that's perfectly fine. In this post I wanted to justify the changes that I'm proposing, because of the consequences. I can also go all the way to a full proposal by myself that programmers can choose to implement or not. In that case I just need an indication that at least one person is interested before I go further.
Thanks for reading,
Fabien.
