Daniel Mehrmann wrote:
Well, the "buffer" is no argument and we talking not about time or ressource critical elements in a chess engine. Further more there is a point, where you need to send all moves to a engine. And who tells you that an engine only pass the moves to update game data and board ?
Well, bear in mind that the starting point for this particular point is the UCCI spec, which states that the GUI
should send the position after the last irreversible move, and the moves since that point. My initial suggestion was to simply ignore that, since the only difference it
should make is in the number of moves that are sent to the engine.
As HGM pointed out, that's no good, since there are (apparently) many UCCI engines out there that will crash if you do that. Now, you can say that that's their problem, but first of all, that's not very useful for a user who wants to run them (especially if chances are slim that the UCCI engine author will fix the problem) and second of all, we're not actually following the protocol spec.
But basicly, and that's the most importent point, i'm missing the real understanding about UCI, how it works and why is it desigend as it is.
No disrespect, but I have the distinct impression that the one who is missing a part of the discussion is you. This isn't about what UCI is or how it should be, or how we can abuse it. This is about UCI, USI and UCCI, which are all basically UCI dialects, and how to write an adapter that can be used to communicate with engines using these protocols.
Now, clearly, if you have something constructive to add here, please do! But I get the impression you just want to make some vaguely negative comments and not be constructive, and I don't really understand why.
The main problem is your personal perspective and thoughts about UCI.
A protocol designer shouldn't think about how things would be going on with his own thoughts. A protocol designer needs to think how other developers might think about it and need to calculate the worse case always.
True, but again: we're not designing anything here. These are existing protocols developed by other people.
In other (hard) words: Developers are basicly "bitches" in the case of laziness. Sometimes they might think on wrong ways and implement wrong things. That should be the default way how to think on protocol things.
Funny you say that, because half the issues that were discussed are work-arounds for faulty engines.
The sanest way to handle communication through a communication protocol is to strictly follow the protocol in what you send to the engine, and cutting the engine some (or a lot of) slack when you interpret what it sends back. Same for communication the other way.
But again, what do you do with USI engines that crash when you send them "winc" commands?
So, what you need is a safe protocol in any stage, any case and any scope. This is the first and most imporent rule. Everything else should never every break this rule and just for example, even if it means that you need to send all moves again, again and again.
Sending all moves again and again does not imply a robust protocol.
But the reason it annoys me personally is that all my programs keep track of their own game history, so when I receive a UCI "go" command I need to first unwind my game history, then step forward through the game again. It would be far easier (
for me) if it just sent the last move instead. Obviously that's simply how my programs work, and it turns out to be a poor fit to UCI. That's why I think it's annoying, but I'm not pretending that it's anything other than my personal opinion.