> > 3. Links to other games requires an additional data file, and an additional > > attribute inside the game data. > > Do you mean you are going to create a 4 file system ?
Yes, a 4 file system is required for this. > I find it hard to see the worth of persistant game links. > > 1. More effort at base compaction/sort > 2. Dereferencing game links makes PGN viewing much more complicated. > 3. (Selective) game copy between database loses data/game links > if referenced games are not also copied. Even if they are - trying > to preserve game links would be very ugly. > 4. You need a good DB design , which can't be hurried. > 5. Scidb' tree shows matched games anyway - at good speed To 1) Yes, but manageable. I have already solved this problems at other places, for example the game editor: if you open some games in a database, and you are compacting the database, all open games will now reference the new game position in the database (middle mouse button in game header will show you the game number in database). To 2) Yes, but expanding the link inside a game is only sugar. The main purpose of a link is the possibility to reference another game, and to allow an easy switch to this game. To 3) That's in fact a problem, and if this is not solvable with a relatively easy handling I have to give up the links. To 5) Scidb is also showing matching games, but a matching game is not in any case a related game. A related game is following the same route as the referencee, for example, but a matching game may be quite different. A linked game is a feature which will be managed by the author, the automatic of game matching doesn't know such things, like the author knows. > With a little effort, we can merge (say) next 10 moves of a referenced game > as a variation with a comment showing the source game info. Scidb can do this, too. But for me it's not elegant to replicate the moves of another game in database. A link which opens the game - Scidb is supporting up to nine open games simultaneously - is comfortable, expanding all the linked games inside the referencee is an additional feature, which can be done with single mouse clicks - or keyboard shortcuts - like folding/unfolding all variations. > This avoids all the pitfalls and complexity of permanent game > links while still providing a good view of the relevant game. Of course managing links is a bit sophisticated, and if the problem with game copy is not easily solvable, then it's unrealistic. My first solution for this problem is the following: A game copy will replace all "hyperlinks" with textual links. Copying this game to another database means, that the former links are now only comments in the copy. With other words: if a game will be copied to another database, the meaning of the link is changing, it's not a "hyperlink" anymore, it's only a textual link - you cannot click it anymore to open the referenced game, and the display of the link will change from a special link layout to a normal comment (should be only a minor difference). Furthermore a hyperlink will always show the actual game information, a textual link is static and will not reflect changes of the linked game anymore. This solution has two drawbacks: 1. I have to modify the copied game. This is realistic only if I can do this in a very simple way - only appending the textual data for the textual links, not more. I don't know yet whether this is realizable. A textual link will have a few more bytes more than an ordinary comment. 2. The copy is not an one-to-one copy. Does anybody know an alternative way to handle game copy? Probably the game copy is smashing the idea with game links. > PS - are you even going to have a permanent sort feature ? I should implement this, so far as I see it's only an update of the index file with the new order. All sorting features are already implemented and usable. Gregor
