I think the real issue is not the total number of commands that a protocol supports but whether the underlying abstraction is sound. I think time has shown that both protocols are sound.hgm wrote:Well, that is what you get for using an inferior protocol. WinBoard / XBoard would support all that, throught the options -firstNPS, -secondNPS.Don wrote:Yes, but remember in UCI the interface sends this information and no interface that I know of knows how to pretend that nodes is time and do the accounting. Have you ever heard of a 40 million nodes in 2 minute time control? No UCI support so you must build it into your tester and also provide a way for the engine to report precisely how many nodes were consumed to the interface and also node forfeits would have be become a reality.
UCI is a stateless protocol and assumes that the engine knows nothing about the state - it is provided by the interface. That makes things simple for the engine implementer and is either an advantage, or a disadvantage depending on your point of view. It's a more modern concept (modular design) but that does not imply that is't always the best thing to do.
Either protocol could benefit in functionality by adding endless numbers of additional "commands" but I personally believe the soundest protocols should be relatively minimalistic and provide the low level functionality to enable third party tools to be easily built that can do most everything one could want.
So in your example the firstNPS functionality could be added to UCI without changing anything - I don't think it reflects on the superiority or inferiority of any particular protocol.