Gregor Cramer schreef op 11/26/2014 4:11 PM: > Thanks for your answer. > > I like to propose some more attributes: Great. Any suggestion for what would be useful is welcome. This is intended to service every conceivable GUI, and some GUIs might value other information than others. So it is good if GUI authors would exchange ideas for how we could extend the standard. It is just that I wanted to start with the absolute minimum requirement (the engine command & optionally directory) as a 'proof of principle'. The addition of the variant list was so that I can already package my Shogi engine with an .eng file listing "shogi", without having to be afraid it would be automatically installed in SCID. > > 1. Short identifier with version number (comma separated), e.g. > "Stockfish, 4.0", or "Crafty, 4.1". > > 2. Name of the origin of this engine (this must not be the author), > e.g. "H.G. Muller", or "Stockfish team". > > There exists so much versions of one engine, and these additional entries > might help the GUI (or user of the GUI) to discard some engines, or to replace > an entry of an older version with a newer version. The name of the > specification file is in general not sufficient for this decision. Files from different sources can only coexist if they have different names, though. (Unless one would happen to be installed from source in /usr/local/... and the other from repo in /usr/..., then there could be two). The name is currently not used at all, though. So perhaps it is an idea to derive the filename from the package name, so that packages from different sources for the same engine (or for different versions of that engine) could coexist, and the GUI could really choose between them based on content, rather than only seeing the last one that overwrote all previous installs. > plugin spec 1.0 > /usr/local/share/games/stockfish-scidb > chess,chess960,threecheck,king-of-the-hill > Stockfish, 4.0 > Scidb For the variant names we still have to think up a good solution, as there is a potential infinity of variants, and listing them all would make the list for some engines very long, and also miss the purpose. Eventually the engine should itself tell the GUI which variants it exactly supports. The purpose of listing variants in the .eng file is to make it possible for the user to define an 'interest group', that would only install engines he might be interested in, and would not bother him with engines he has no interest in at all. If he would have to specify each individual variant he is interested in, this would not be possible, as there could be variants no one has ever heard of. So I was thinking more of listing 'variant families' of variants that are similar enough that is one is interested in one of them, there is a reasonable likelyhood one would also be interested in the others. Obviously the worlds major chess variants like chess, xiangqi and shogi should be in 'families' of their own, as there are plenty of people that are only interested in 'orthodox' games, and many GUIs that only support those. But 3check and KotH would nicely fit in the same family, namely "Chess with standard material but an alternative winning condition". For this group it is also likely that a normal Chess GUI could use them, which would be out of the question with engines for, say Capablanca Chess. > So any other GUI has the chance to discard Scidb's special version, e.g. for > Scid only the original Stockfish version is of interest. Not writing any > specification file for these engines is not the solution for me, probably any > other GUI, e.g. specialized for King-of-the-Hill, might be interested to use > Scidb's engines, and Scidb will use these specification files for the auto- > installation of his own engines. Indeed, that is exactly the idea of the whole system. It is very unlikely, though, that there would ever be a GUI that can only support KotH, as it is so similar in requirements to ordinary Chess or 3check. If you think SCID should not install the engine, the logical solution would be to not list "chess". OTOH, there does not seem great harm if the engine was installed in SCID as a duplicate of Stockfish. > Another proposal: IMO the use of line numbers for the definition of attributes > is not very common, I think that named attributes will make the editing of > specification files easier, example: > > [Plugin Spec] > Command=/usr/local/share/games/stockfish-scidb > Path=/usr/local/share/scidb-beta/stockfish > Icon=/usr/local/share/scidb-beta/playerbase/photos/38/163494 > Variants=chess,chess960,threecheck,king-of-the-hill > Identifier=Stockfish > Version=4.0 > Source=Scidb This was also the preference of the ChessX developers. I am not against it, but the problem is that the current situation is that the version of XBoard that is currently in Debian already uses the 0.0 format, and several engines already package those files. But for the next version of the specs we could switch to it. The argument on the parsing seems a bit spacious, though: there are plenty of 'parsers' that just read an entire line. If the line is a list, it needs further parsing anyway.
More later. H.G. > Some more features of this format: > > 1. In this way the parser for a well known format can be used, this format is > also well known for Linux users - not only for Windows users - e.g. > freedesktop.org (KDE, GNOME, XFCE) is using this format for desktop > specification files. > > 2. This format is extensible without any version number change, hence the > version number can be omitted. > > 3. This format allows private extensions, because any unknown attribute will > be skipped. > > 4. An icon must not have a suffix (on Linux systems), and the name of the icon > might be different from the engines name, so the generic player > photos of Scidb can be used with the proposed format (see Icon=...; Scidb > is using internal ID's for players and engines, because a name is in > general not unique). Your original proposal is automatically adding > standard image suffixes, this is not common under Linux, and it makes the > use of Scidb's player photo files impossible; beside the fact that Scidb > is using ID's instead of names. In this way, with an explicit > specification of the image file, it is also possible to share logos. > > 5. This specification format can also be used easily under Windows (if > required). Of course, Linux and Windows needs different contents. > > Cheers, > Gregor Cramer > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Scid-users mailing list > Scid-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/scid-users > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
