Alexander Wagner a écrit : > [...] > > So, from this point of view I'm staring to consider redoing > dgt-support in tcl. BUT: this will take time and NOT make > the interface where I could hook up anything obsolete. This > interface is IMHO quite a bit more universal. It's two ways > of doing things, and though you added fics already and > besides that I do not have a concrete idea for another app > IMHO interfaces are of great importance. (My job e.g. > involves quite a bit of work with a large DB that does not > have suitable interfaces on my level of access as I can't > use the pure SQL. And this creates a bunch of work > arrounds.) > > Doing dgt support in pure TCL requires me to _recode_ the > entire dgtnix in TCL, that is all the hardware stuff, plus > recoding the entire dgtdrv. The latter is IMHO only time > consuming whereas the former is a bit more involved. Anyway, > I'm really considering this. This approach will have some > disadvantage, however: it requires quite a bit of code just > to get the dgt to work. It will require almost the same > ammount to get X to work and Y and again for Z. The really > sad thing here is that scid is in TCL. I do not speak that > language fluently. So it takes even longer. > To recode DGT support in Tcl will add portability as it is more portable than C/C++. If you consider FICS support, I think this is more complex than DGT support. To support DGT you will only need to handle moves, where for FICS you have to code things like "find opponent", "observe games", "login as guest" etc... So if you look at FICS code you will notice how simple it is, even with such a complex protocol as FICS. So from my point of view Tcl is the easiest way, and more portable than other languages.
Moreover a DGT board is not an UCI engine, neither is a connection to play on internet : I could have written a FICS interface as a chess engine for example but this would have been so artificial that I would have had big problems working that way. And I am convinced it is the same for a DGT board : there are subtle things that are not handled by the UCI protocol. The benefits of reusing UCI engines handling by user interfaces (xboard, Scid,...) is overwhelmed by UCI protocol limitations. Pascal ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
